@xj9 @thezacattacks Aesthetically, #guix wins every time. And in some practical terms too. On #nix I go out of my way to avoid interpreting the whole package tree, on guix it is compiled and I just address packages by name, not by exact property. Guix also has sophisticated ways to express system configuration and relationships between services, that I believe Nix lacks.
I have to admit though, #guix pull is super slow because it compiles the whole package tree. The upgrade to Guile 2.2 is awesome in terms of runtime performance, but it didn't exactly help compilation times.
Guix is also constantly evolving its packaging interface, which means you have to stay up-to-date on the upgrade treadmill. I praised it the other week[0] that they had improved this a bit, but the solution suggested didn't actually work -- I had to[1] go and get the 0.13.0 binaries to go forward.
In terms of Worse is Better, Guix is MIT, Nix is Berkeley. In the long term, Guix is more principled, but in the here and now, Nix gets things done.
[0] https://social.heldscal.la/notice/3435628 [1] Well, chose to, rather than try to track down exactly which revision I would have to pull to get ahead. Maybe it would have been so easy as to pull just the revision one later.
On my Mac laptop obviously there is no Guix. On my GNU laptop, guix pull takes a whole day. Haven't updated it for months. And now that I'm actively working on Nix stuff, that puts Guix even more in the background.
Once I get #racket2nix working for real (but it's already a minimally useful thing!), I will look at making a guix import racket though. That will have to be in a VM on the Mac, unless I went and got myself a more powerful GNU by then.