It's indeed a really nice presentation!
Unfortunately the common roots with #nix and the shared daemon code are more or less forgotten now and suppressed by an all-dominating "scheme and nothing else" ideology. This makes the project utterly blind for any interesting development and improvement attempts going on in the nix sphere -- e.g. the #snix efforts.
@sharlatan @khleedril @snamellit
> time for Golang and Node.js ;-)
A nice #deno integration would be indeed a very useful improvement.
The rust improvements are indeed nice, but they are still unusable on little RISC-V devices, because we don't provide enough substitutes for this platform until now and the horrible rust bootstrap tradition would require to build a whole chain of `rustc` versions before you can use any guix managed rust application on your system. That's why I'm still using plain `rustup` and `cargo` for all rust related work on these devices.
@craigbro There is already a merge request available for your issue:
https://codeberg.org/guix/guix/pulls/1207
It's only affecting *old* installations (e.g., the official 1.4 release binaries) and riscv64 SoCs with >= 8 cores. It's already fixed in newer `gnulib` releases, but the way how #guix works, perfectly reproduces this historic bug as well.
Modify `gnulib-tests/test-lock.c` to prevent failures and crashes on riscv64. It only disables the execution of `rwlock` tests of `test-lock`, one of the `gnulib-tests`, for the `riscv64` platform. Fixes: #1161 These modifications alter the build check phase of: - findutils - libunistring...