I've been using Guix for about the last year and a half at this point (and is coincidentally most of what I post about on this site) and Guix certainly has its ups and downs. Most notably, for me, Guix is leagues slower than Nix it seems, since I use both on my system with Guix as the main distro. Also, just generally less packages and the ones that are present are out of date. However, the architecture of Guix means it can be extremely easy to bump versions of packages as long as dependencies or build options haven't changed too drastically. You will inevitably need to run your own channel on top of your system to actually house these version bumps (before you upstream them!) and packages that you package yourself (again, try to upstream if applicable!). I'd say that about 30-40% of my packages have been modified by me in some way or another, whether it be a complete rewrite of the definition, build option modifications, or just a simple version bump while we wait for it to appear in the upstream repo (more "core" packages, like bluez and those type, get updated less often since that triggers a rebuild of all packages that may depend on it). It definitely isn't for the faint of heart, but I find it rewarding.<p>Some exciting changes are upcoming too, like the addition of being able to boot from UKIs rather than being stuck with GRUB, which probably won't happen for a bit still, however I think this ties into the broader "issue" with Guix.<p>The community is small, which is definitely a result of it (just like Nix) being more complex than the average distro that people do not want to deal with, compounded by the fact that it uses even <i>less</i> standard utilities to build the system (like not using systemd as a service manager in lieu of shepherd). I feel a lot of the pain points that Guix has can be addressed just by having more eyes and hands on the project. If anyone has more specific questions on using Guix I'd be more than happy to give my view.