@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.