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:
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:
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:
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:
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.
Thanks for taking the time to write a up a detailed and informative answer!
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).
With regards to needing patches, the comments in this thread suggested many packages needed patching to work on NixOS at run-time, but I have probably misunderstood.
At build time obviously Guix has all the same problems with packages that attempts network access (to download test data or whatever). I found it easier/more intuitive to provide such additional resources with Guix, but then it's been four years since I used Nix!
On the topic of search paths, IIRC Nix uses a combination of wrappers and "setup hooks" to configure things like C_INCLUDE_PATH or PYTHONPATH. In Guix, such search paths are "first class" and gets automatically configured when the relevant packages are installed to a profile.
That means no hook or wrapper is necessary, and it works with arbitrary profiles as well as "guix pack", etc -- and it is also possible to compose profiles (an emerging pattern among Guix users is to have different profiles for different uses -- a step towards privilege separation).
You'll find almost no hard coded references to "~/.guix-profile" or "/run/current-system" in Guix.
Wrt the updater code, apparently you have studied it more than I have! I think my point still stands though -- that approach would not work if not for the fact that sexps are well-structured.
In Guix search paths are properties of the packages that consume them: for the GStreamer example in that PR all the plugins provide the search path attribute, whereas in Guix it is only set once, on the 'gstreamer' package.
The Guix approach has a limitation though, in that users must manually install gstreamer for the plugins to become visible in the profile. It's one of the oldest high-severity bugs in Guix: https://issues.guix.gnu.org/22138
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.