Not OP, but I've been daily driving Guix for about 5 years now quite happily. The biggest paint point with vanilla Guix is probably a lack of non-libre packages, especially the linux-libre kernel which strips out blobs. However, the nonguix [1] channel handily fills that hole, and there is first-class support for running a Nix daemon service [0] to cover anything not in nonguix.
Guix documentation is top notch, and it's really nice having all that available locally as texinfo pages. For writing packages yourself, I've found the Guix source to be eminently more greppable than Nix, which eases the dev onramp.
Nix's daemon is definitely more performant than Guix's, so equivalent operations will usually be quite a bit slower in Guix, but on the whole I'd say that Guix's more cohesive design makes the system more pleasant to work with.
(I know I could just RTFM but since you offered!) Does it do something like NixOS for declaring modules as functions and resolving the configuration as a fixed point of all module function applications (roughly, I don't think I'm describing it well)? This is a beautifully elegant way of defining configuration-with-options using lazy evaluation but it often leads to headaches like infinite recursion. Since Guile is not a lazy language I wonder how it achieves this.
I don’t know how Guile does this, but note that finding a fixed point does not generally require a lazy language; you just can’t do it naively — you can still take a bunch of functions that act on a config and ‘while (changing) keep applying’ — equivalently, the Y combinator can’t be evaluated strictly to get your fixed points, but the Z combinator can.
In all honesty, I don't know what that means, but the way Guix does configuration is with the Lisp equivalent of a builder pattern, which ends up looking quite like a key-value store.
Guix documentation is top notch, and it's really nice having all that available locally as texinfo pages. For writing packages yourself, I've found the Guix source to be eminently more greppable than Nix, which eases the dev onramp.
Nix's daemon is definitely more performant than Guix's, so equivalent operations will usually be quite a bit slower in Guix, but on the whole I'd say that Guix's more cohesive design makes the system more pleasant to work with.
Happy to help if you have any specific questions!
[0] https://guix.gnu.org/manual/en/guix.html#Nix-service
[1] https://gitlab.com/nonguix/nonguix/