| There are quite a few HPC clusters that are powered by Guix: https://hpc.guix.info/about/ Whether or not these institutions qualify as Real Companies is up to you. Other than that I occasionally see focused patches and bug reports from people using their work credentials, but nothing on the scale of Pinterest and Target of course. We did recently get a bugfix for 'guix system container' from Google, but I suspect that was more the result of an evaluation than anything else: https://issues.guix.gnu.org/43540 As for benefits in a professional setting, there are a few design (and implementation) differences that I think gives Guix an edge. One is grafts: Guix can deliver security updates for core packages really fast, whereas Nix needs to rebuild every dependent package. The grafting mechanism can also be used to perform other transformations, e.g. to locally enable CPU optimizations for low-level libraries without having to rebuild the world. On the topic of security, Guix has a strong focus on bootstrapping, meaning that e.g. the Rust and Java compilers are built purely from source code, whereas Nixpkgs use opaque binaries provided by upstream projects. This property (as well as excellent cross-compilation support) is why Bitcoin chose Guix to build their installers: https://bitcoinmagazine.com/articles/guix-makes-bitcoin-core... Another important design difference is gratuitous use of so-called "search paths". I noticed one common criticism in this thread is that packages often needs patching to work in NixOS. In Guix, such cases are very rare. Take a look at the patches carried by Guix, conveniently stored in a single directory: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages... By and large, these are just security- or bug (often test suite) fixes. I won't go into detail on how search paths work, but if you try Guix on any distro (maybe except Guix System) you'll quickly understand. It's funny that you mention "non-machine editable Scheme code". In the Lisp world, code is data, which powers among other things the "updaters" in Guix: 'guix refresh -u foo' will update the "version" and "sha256" fields of "foo" in your git checkout. Finally, a huge selling point for me personally, is general scriptability. I recently added code to build Chromium extensions with Guix. It was about 150 lines of code, and packaging extensions is pretty much like packaging anything else: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/ch... https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages... There are many other things of less importance that makes me stick to Guix, such as running the test suites of most packages, largely preventing compatibility and other run-time problems that occasionally show up in Nixpkgs (and even popular distros like Arch). Now, the end user experience of Guix System is not great due to lack of proprietary firmware, as well as GNOME and KDE maintainers, but as a professional tool Guix is really solid in my (supremely biased) opinion. |
I agree wrt desirability of grafts as an escape hatch (I think there's been some undocumented crappy version of this in nix for ages, no idea what keeps it in limbo). I also agree that bootstrapping is better in principle.
The search path (in nix?) thing, I don't fully get -- can you expand what you mean? Concerning not needing to patch upstream -- the world is full of setup.py scripts and other cruft that tries to download random stuff from the internet or write and read hardcoded system paths -- how do you deal with that?
> It's funny that you mention "non-machine editable Scheme code". In the Lisp world, code is data
One of the ego-salving lies lispers like to tell themselves ;) If it were so they'd enjoy world class refactoring, whereas in reality they can't even auto-indent code without manually futzing around with symbol properties in emacs. I haven't fully traced how guix update works, but looking at edit-expression it doesn't look very code-is-data to me (the replacement function operates at character not ast/sexp level; read is only called for side-effect as a hack twice).