I'd love to use Guix (or Nix for that matter) as my day-to-day system but (and correct me, if I'm wrong) the package maintainer story is a bit off putting for me. From what I've understood, packages are maintained in a public git repository (GitHub [0] for Nix and savannah.gnu.org [1] for Guix), which might be great if there are enough people submitting updates, but at least for critical system components there should be clearly defined maintainers to make sure all security patches are applied in time.
Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company. On the other hand GitHub might be more reliable and better fit to server a huge amount of users than savannah...
1. Each package in Nixpkgs repo has assigned maintainer mentioned in source.
2. Nothing prevents you from using your own repo/hosting solution for Nix channel.
3. Writing or overwriting packages in Nix is dumb easy, so I do not see a problem here as well.
I started using Nix exclusively on macOS and I couldn't be happier. The best part IMHO is the fact that I can easily test different packages without permanently changing my system and dealing with clutter left by these.
So in general, this is less of the problem that you think it is, especially as you clone that repo locally, so you do not hit GH/Savannah on each installation.
I have the same experience. Using NixOS, not just NixPkgs, but it shouldn't matter.
Nix takes security very seriously. See e.g. [1]. Plus, a distribution that defines packages declaratively and makes things so reproducible is the ultimate tool to avoid many security issues.
In Guix we came to the conclusion [2] that having shared package “ownership”—or, to put it differently, not having explicit ownership—is a solution that works best for us. In practice, most packages have a few associated experts who take care of most updates and fixes to them. However, as a group, the fact that there’s no name explicitly attached to the package means that every committer can feel empowered to modify it.
The pros and cons of per-package maintainers are often debated, notably in the context of Debian where strong ownership has shown its limits [3].
I actually see the just-a-git-project aspect of the Nix/Guix distribution maintenance a massive win on transparency grounds. I agree that I'd like to see a bit more dedicated "ownership" of key components, but I see that more as a lack of manpower meaning that many people have to spread themselves quite broadly.
But at the same time I'm quite hopeful that this model can produce a maintenance culture that's less territorial, arcane and officious than is my impression of e.g. Debian's methods and processes. As much as I love Debian, of course - but it definitely feels like yesterday's approach.
I also guessed that the lack of dedicated maintainers is due to a lack of volunteers, but that's something that stops me from using either guix or Nix at least from handling the critical part of my OS (kernel and base system).
For development environments and other stuff, both are great tools, but I guess the real power comes when you manage the whole system through any of these managers.
> Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company.
If it brings any solace: your current OS is using code hosted on GitHub.
What you say is akin to disliking HTTPS and the CA system. People on whom you depend, depend on it. The internet depends on it. Therefore, you are using it. Same with BGP. Same with IPv4. Same with 2G.
No "core part" of Guix is hosted on Github. If you're referring to the daemon: it's being replaced with a Guile implementation (it's an ongoing student project). It's not fetched from Github; our old copy of the daemon is part of the Guix git repository.
Sorry for being unclear. The part about being hosted on GitHub actually referred to Nix. That's the point where I'm unclear about what seems to be the better solution. GitHub could take a turn for the worse but at least for now, GitHub might be able to handle more users than savannah.
Looks like a neat concept. Would anyone here with experience managing this in production care to comment? Seems like it could be interesting if you need to reproduce the exact same software/OS on several machines as deliverables.
I've been using Guix in production since 2014 at a research institute to support reproducible bioinformatics workflows. It has come a long way since then.
Guix takes reproducibility and "bootstrappability" very seriously. Its design as an extension to Guile Scheme enabled the development of software built around Guix, such as a workflow language, alternative user interfaces (e.g. an Emacs interface or a web interface), etc.
The `guix system` family of commands is awesome because it can build reproducible containers, disk images, virtual machines, or bare-metal systems all from the same specifications.
What's still missing, in my opinion, is a tool to manage systems that have been generated with Guix, e.g. to check on their state, build new configurations and swap them out for old ones, etc. Some work has been done towards this goal, but there's still some way to go there.
Other than that I'm very happy with it and use Guix systems and Guix as a package manager on all my machines.
How does writing Guix Lisp expressions compare to writing Nix? Is it pretty succinct and intuitive? Do patterns make a little bit better sense?
It took me a long time to get the hang of the Nix design patterns like the three different kinds of overrides and the module system. Curious if it plays better in Lisp.
I use nix in production, and it is amazing. It's super config management on steroids with the ability to roll back in a literal instant.
Guix is based off nix, I have looked at it a few times, but it seems much more complicated and less developed than nix. It's only selling point over nix if that everything is written in guile, which does not matter to me.
Many people run Nix in production — a similarly structured OS. Nix works fine. GUIX is relatively new; I played with it, but didn’t use in production yet.
This seems like a large piece of software. I'm interested in the purely functional, portable package manager aspect. I can see that it has [0] a lot of packages that are a pain to build on my Slackware system (or even to download prebuilt) because of the awesome number of dependencies. Downloading mpv and its dependencies takes quite a bit of time, for example. If anyone has experience with using guix this way, I'd be interested.
At the beginning of this year I got hooked-up on this concept of functional system and package management. I've read through all the Nix documentation trying to get a feeling of how should I use it. And it just felt bad - sometimes the documentation was outdated, sometimes it clearly contradicts code on master, sometimes the programming style was inconsistent, sometimes the examples were unclear, too simple or too contrived... Thousand ways to achieve the same things and no clear "best practices" way.
Is guix's documentation any better? I mean - teach me the theory, but also show me practical examples making use of it so I could remember?
Yes, but not only : "GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines."
I've been using the Guix system since early 2018. It's a lot of fun. I've put off some of the more complicated stuff (from a user's perspective) like packaging new things, but it's managed to stay my daily driver just fine.
I haven't been active for a couple of years, but I've contributed my fair share of packages and features since 2013 that I'm proud to see have made it all the way to 1.0. Congrats, Guix team!
As a person with ~intermediate knowledge of Nix/NixOS and only knowing Guix from a distance yet:
- I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now?
- (How) can I pin my whole config to a particular commit of the package set/channel, and only update gradually? I'm kinda having trouble finding out how to do this in NixOS
- Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels? I know GNU proper doesn't want me to do this, and I'm sympathetic, but not ready for the jump. What's the situation for me in practice?
- Can I replace kernel with L4Linux? I tried to do that in NixOS but gave up because of complexity.
- Does GNU mirror/archive all package sources used by Guix somewhere? If github is sunset by MS, can I still build an OS from a 2018 snapshot?
- What's the multi-user story? In Nix it's complicated.
- Does Guix have something like Nix's home-manager?
> - I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now?
Yes. GuixSD is now called "Guix System".
> can I pin my whole config to a particular commit of the package set/channel
Yes, you can. You only need to describe the channels you want to use (and possibly their commits) in ~/.config/guix/channels.scm and then run "guix pull". You now have that particular version of Guix and it won't change until you change the channel specification and run "guix pull" again. That's great for reproducing a system elsewhere or at a different point in time.
> Can I replace kernel with L4Linux
I don't know if anyone has tried.
> Does GNU mirror/archive all package sources used by Guix somewhere
We cache sources for as long as possible on the build farm; we also fall back to looking up sources through Nix caches; and finally we fall back to the Software Heritage archive.
> Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels?
Yes and yes. Adding channels is easy: just add a specification to ~/.config/guix/channels.scm
> Does Guix have something like Nix's home-manager
Sadly it doesn't. I'd love to see something like this in Guix.
Thanks! How about the multi-user story for non-OS Guix?
Also, can you share some links to third-party non-libre package sets/channels, or some place where I can find them to see what's available?
Edit: As to kernel: are you using Hurd, or Linux? Or any one of them can be chosen? If it's choosable, I imagine L4Linux should not be that hard. Edit 2: I see there was some work being done on this: https://www.gnu.org/software/guix/blog/tags/gnuhurd/ but last news seems to be from Feb 2017. Did the work get integrated into trunk, or did it bitrot in an old branch? Edit 3: Found some info: http://lists.gnu.org/archive/html/guix-devel/2019-04/msg0023... IIUC, not very stable (missing some Shepherd stuff?), but at least the work seems upstreamed (?)
Just for context to the GP, Nix channels work basically the exact same way. Or, you can do as I do, and not use channels and always specify the exact nixpkgs revision as part of your Nix file. Anyone can `nix-build chimera.nix` and get a (nearly) bit-for-bit identical build of my laptop, which is great - we don't have to have a conversation about which channel I'm on, or which rev of which channel I'm on, etc.
I can then independently rev the nixpkgs revision and either commit that, or not.
Here's something I wrote a few months ago (with minor changes) to clarify the relationship between these two projects. I hope this helps.
-------------------
As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what I consider some important unique features of Guix:
- Guix is all written in Guile Scheme (with the exception of parts of the inherited daemon, which hasn't yet been completely implemented in Guile); this extends to development tools like importers, updaters, to user tools like "guix environment", and even bleeds into other projects that are used by Guix System (the GNU system distribution built around Guix), such as the shepherd init system. There is a lot of code reuse across the stack, which makes hacking on Guix really fun and smooth.
- Packages are first class citizens in Guix. In Nix the idea of functional package management is very obvious in the way that packages are defined, namely as functions. These functions take their concrete inputs from an enormous mapping. In Guix you define first-class package values as Scheme variables. These package values reference other package values, which leads to a lazily constructed graph of packages. This emergent graph can be used as a library to trivially build other tools like "guix graph" (for visualising the graph in various ways) or "guix web" (for a web interface to installing and searching packages), "guix refresh" (for updating package definitions), a lovely feature-rich Emacs interface etc.
- Embedded DSL. Since Guix is written in Scheme---a language for writing languages---it was an obvious choice to embed the package DSL in the host language Scheme instead of implementing a separate language that needs a custom interpreter. This is great for hacking on Guix, because you can use all the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a debugger, etc. With its support for hygienic macros, Scheme is also a perfect vehicle to implement features like monads (we use a monadic interface for talking to the daemon) and to implement other convenient abstractions.
- Graph rewriting. Having everything defined as regular Scheme values means that you can almost trivially go through the package graph and rewrite things, e.g. to replace one variant of a package with a different one. Your software environment is just a Scheme value and can be inspected or precisely modified with a simple Scheme API.
- Code staging. Thanks to different ways of quoting code (plain S-expressions and package-aware G-expressions), we use Scheme at all stages: on the "host side" as well as on the "build side". Instead of gluing together shell snippets to be run by the daemon we work with the AST of Scheme code at all stages. If you're interested in code staging I recommend reading this paper: https://hal.inria.fr/hal-01580582/en
- Bootstrapping. Some of us are very active in the "bootstrappable builds" community (see http://bootstrappable.org) and are working towards full bootstrap paths for self-hosting compilers and build systems. One result is a working bootstrap path of the JDK from C (using jikes, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping problems serious and prefer to take the longer way to build things fully from source instead of just adding more binary blobs. This means that we cannot always package as many things as quickly as others (e.g. Java libraries are hard to build recursively from source). I'm currently working on bootstrapping GHC without GHC and without the generated C code, but via interpreting a variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme.
- Guix System, the GNU system distribution built around Guix. Guix System has many features that are very different from NixOS. The declarative configuration in Scheme includes system facilities, which also form a graph that can be inspected and extended; this allows for the definition of complex system facilities that abstract over co-dependent services and service configurations. Guix System provides more Scheme APIs that apply to the whole system, turning your operating system into a Scheme library.
- I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many perceived problems with the UI have been addressed, of course, but hey, I still prefer the Guix way. I also really like the Emacs interface, which is absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D buffers over 1D command line strings.)
- It's what I want GNU to be. I'm a GNU hacker and to me Guix is a representative of a modern and innovative GNU. It's great to see more GNU projects acting as one within the context of Guix to provide an experience that is greater than the sum of its parts. Work on Guix affected other GNU packages such as the Hurd, Guile, Mes, cool Guile libraries, and led to a bunch of new GNU packages such as a workflow language for scientific computing.
On the other hand, although Guix has a lot of regular contributors and is very active, Nix currently has more contributors than Guix. Guix is a younger project. The tendency to take bootstrapping problems very seriously means that sometimes difficult packages require more work. Oddly, Guix seems to attract more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with Scheme after watching the SICP lecture videos); it seems to be the other way around with Nix.
Having said all that: Nix and Guix are both implementations of functional package management. Both projects solve similar problems and both are active in the reproducible builds efforts. Solutions that were found by Nix devs sometimes make their way into Guix and vice versa. The projects are not competing with one another (there are orders of magnitudes more people out there who use neither Guix nor Nix than there are users of functional package managers, so there's no point in trying to get people who use Nix to switch to Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who invented functional package management and Nix) gave a talk on the future of Nix surrounded by Guix hackers --- there is no rivalry between these two projects.
----
Now to the last question: How usable are they? I've been using Guix (as a package manager and as an OS) since 2014 on all of my machines and I love it. I have written hundreds of package definitions both manually and with the help of "guix import", which generates them for me (even recursively). If you're okay with Lisp it's not painful at all. I have experience with RPM spec files and Arch PKGBUILDs and I love how declarative Guix package definitions are in comparison. For well-behaved projects that's great. For projects that reinvent build systems or come with custom build instructions or that assume unreasonable things about the target system things can get pretty gnarly, though.
Guix differs in that you don't use shell snippets to describe the installation steps. This can be confusing for people coming from other packaging systems, and it can be a little uncomfortable having to express things in Scheme instead. On the plus side you have access to a much more flexible language and don't have to mess with low-level shell. You can write procedures and reuse them across packages, or you can abstract the whole build process so that all that is ever needed is a declaration like `(build-system python-build-system)'.
(Things that suck: packaging NPM/nodejs things. Guix folks are really into building things from source, and there's a cultural mismatch with NPM folks. There are workarounds but there's no silver bullet.)
Readit News
Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company. On the other hand GitHub might be more reliable and better fit to server a huge amount of users than savannah...
[0]: https://github.com/NixOS/nixpkgs
[1]: https://git.savannah.gnu.org/cgit/guix.git/
I started using Nix exclusively on macOS and I couldn't be happier. The best part IMHO is the fact that I can easily test different packages without permanently changing my system and dealing with clutter left by these.
So in general, this is less of the problem that you think it is, especially as you clone that repo locally, so you do not hit GH/Savannah on each installation.
Nix takes security very seriously. See e.g. [1]. Plus, a distribution that defines packages declaratively and makes things so reproducible is the ultimate tool to avoid many security issues.
[1] https://github.com/flyingcircusio/vulnix
I actually added the per-package ‘maintainers’ field in Nixpkgs [0] and removed it in Guix [1]. :-)
[0] https://github.com/NixOS/nixpkgs/commit/7b7ed8f1af447f7d2ddb...
[1] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=154f1f...
In Guix we came to the conclusion [2] that having shared package “ownership”—or, to put it differently, not having explicit ownership—is a solution that works best for us. In practice, most packages have a few associated experts who take care of most updates and fixes to them. However, as a group, the fact that there’s no name explicitly attached to the package means that every committer can feel empowered to modify it.
The pros and cons of per-package maintainers are often debated, notably in the context of Debian where strong ownership has shown its limits [3].
[2] https://lists.gnu.org/archive/html/guix-devel/2015-12/msg000...
[3] https://lwn.net/Articles/708163/
But at the same time I'm quite hopeful that this model can produce a maintenance culture that's less territorial, arcane and officious than is my impression of e.g. Debian's methods and processes. As much as I love Debian, of course - but it definitely feels like yesterday's approach.
For development environments and other stuff, both are great tools, but I guess the real power comes when you manage the whole system through any of these managers.
If it brings any solace: your current OS is using code hosted on GitHub.
What you say is akin to disliking HTTPS and the CA system. People on whom you depend, depend on it. The internet depends on it. Therefore, you are using it. Same with BGP. Same with IPv4. Same with 2G.
Deleted Comment
Guix takes reproducibility and "bootstrappability" very seriously. Its design as an extension to Guile Scheme enabled the development of software built around Guix, such as a workflow language, alternative user interfaces (e.g. an Emacs interface or a web interface), etc.
The `guix system` family of commands is awesome because it can build reproducible containers, disk images, virtual machines, or bare-metal systems all from the same specifications.
What's still missing, in my opinion, is a tool to manage systems that have been generated with Guix, e.g. to check on their state, build new configurations and swap them out for old ones, etc. Some work has been done towards this goal, but there's still some way to go there.
Other than that I'm very happy with it and use Guix systems and Guix as a package manager on all my machines.
It took me a long time to get the hang of the Nix design patterns like the three different kinds of overrides and the module system. Curious if it plays better in Lisp.
Guix is based off nix, I have looked at it a few times, but it seems much more complicated and less developed than nix. It's only selling point over nix if that everything is written in guile, which does not matter to me.
[0] https://www.gnu.org/software/guix/packages
Is guix's documentation any better? I mean - teach me the theory, but also show me practical examples making use of it so I could remember?
I've never found the documentation to be outdated or grossly misleading.
That's because Guix is an operating system :D
https://www.gnu.org/software/guix
- I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now?
- (How) can I pin my whole config to a particular commit of the package set/channel, and only update gradually? I'm kinda having trouble finding out how to do this in NixOS
- Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels? I know GNU proper doesn't want me to do this, and I'm sympathetic, but not ready for the jump. What's the situation for me in practice?
- Can I replace kernel with L4Linux? I tried to do that in NixOS but gave up because of complexity.
- Does GNU mirror/archive all package sources used by Guix somewhere? If github is sunset by MS, can I still build an OS from a 2018 snapshot?
- What's the multi-user story? In Nix it's complicated.
- Does Guix have something like Nix's home-manager?
TIA!
Yes. GuixSD is now called "Guix System".
> can I pin my whole config to a particular commit of the package set/channel
Yes, you can. You only need to describe the channels you want to use (and possibly their commits) in ~/.config/guix/channels.scm and then run "guix pull". You now have that particular version of Guix and it won't change until you change the channel specification and run "guix pull" again. That's great for reproducing a system elsewhere or at a different point in time.
> Can I replace kernel with L4Linux
I don't know if anyone has tried.
> Does GNU mirror/archive all package sources used by Guix somewhere
We cache sources for as long as possible on the build farm; we also fall back to looking up sources through Nix caches; and finally we fall back to the Software Heritage archive.
> Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels?
Yes and yes. Adding channels is easy: just add a specification to ~/.config/guix/channels.scm
> Does Guix have something like Nix's home-manager
Sadly it doesn't. I'd love to see something like this in Guix.
Also, can you share some links to third-party non-libre package sets/channels, or some place where I can find them to see what's available?
Edit: As to kernel: are you using Hurd, or Linux? Or any one of them can be chosen? If it's choosable, I imagine L4Linux should not be that hard. Edit 2: I see there was some work being done on this: https://www.gnu.org/software/guix/blog/tags/gnuhurd/ but last news seems to be from Feb 2017. Did the work get integrated into trunk, or did it bitrot in an old branch? Edit 3: Found some info: http://lists.gnu.org/archive/html/guix-devel/2019-04/msg0023... IIUC, not very stable (missing some Shepherd stuff?), but at least the work seems upstreamed (?)
I can then independently rev the nixpkgs revision and either commit that, or not.
Guix: An advanced operating system (4 months ago, 313 points, 168 comments) https://news.ycombinator.com/item?id=18902823
Software Heritage and GNU Guix join forces to enable long term reproducibility (13 days ago, 168 points, 7 comments) https://news.ycombinator.com/item?id=19699031
As in:
- What differentiates the two?
- What are respective drawbacks / advantages?
- How usable are they? How painful is the manual creation of packages?
-------------------
As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what I consider some important unique features of Guix:
- Guix is all written in Guile Scheme (with the exception of parts of the inherited daemon, which hasn't yet been completely implemented in Guile); this extends to development tools like importers, updaters, to user tools like "guix environment", and even bleeds into other projects that are used by Guix System (the GNU system distribution built around Guix), such as the shepherd init system. There is a lot of code reuse across the stack, which makes hacking on Guix really fun and smooth.
- Packages are first class citizens in Guix. In Nix the idea of functional package management is very obvious in the way that packages are defined, namely as functions. These functions take their concrete inputs from an enormous mapping. In Guix you define first-class package values as Scheme variables. These package values reference other package values, which leads to a lazily constructed graph of packages. This emergent graph can be used as a library to trivially build other tools like "guix graph" (for visualising the graph in various ways) or "guix web" (for a web interface to installing and searching packages), "guix refresh" (for updating package definitions), a lovely feature-rich Emacs interface etc.
- Embedded DSL. Since Guix is written in Scheme---a language for writing languages---it was an obvious choice to embed the package DSL in the host language Scheme instead of implementing a separate language that needs a custom interpreter. This is great for hacking on Guix, because you can use all the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a debugger, etc. With its support for hygienic macros, Scheme is also a perfect vehicle to implement features like monads (we use a monadic interface for talking to the daemon) and to implement other convenient abstractions.
- Graph rewriting. Having everything defined as regular Scheme values means that you can almost trivially go through the package graph and rewrite things, e.g. to replace one variant of a package with a different one. Your software environment is just a Scheme value and can be inspected or precisely modified with a simple Scheme API.
- Code staging. Thanks to different ways of quoting code (plain S-expressions and package-aware G-expressions), we use Scheme at all stages: on the "host side" as well as on the "build side". Instead of gluing together shell snippets to be run by the daemon we work with the AST of Scheme code at all stages. If you're interested in code staging I recommend reading this paper: https://hal.inria.fr/hal-01580582/en
- Bootstrapping. Some of us are very active in the "bootstrappable builds" community (see http://bootstrappable.org) and are working towards full bootstrap paths for self-hosting compilers and build systems. One result is a working bootstrap path of the JDK from C (using jikes, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping problems serious and prefer to take the longer way to build things fully from source instead of just adding more binary blobs. This means that we cannot always package as many things as quickly as others (e.g. Java libraries are hard to build recursively from source). I'm currently working on bootstrapping GHC without GHC and without the generated C code, but via interpreting a variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme.
- Guix System, the GNU system distribution built around Guix. Guix System has many features that are very different from NixOS. The declarative configuration in Scheme includes system facilities, which also form a graph that can be inspected and extended; this allows for the definition of complex system facilities that abstract over co-dependent services and service configurations. Guix System provides more Scheme APIs that apply to the whole system, turning your operating system into a Scheme library.
- I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many perceived problems with the UI have been addressed, of course, but hey, I still prefer the Guix way. I also really like the Emacs interface, which is absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D buffers over 1D command line strings.)
- It's what I want GNU to be. I'm a GNU hacker and to me Guix is a representative of a modern and innovative GNU. It's great to see more GNU projects acting as one within the context of Guix to provide an experience that is greater than the sum of its parts. Work on Guix affected other GNU packages such as the Hurd, Guile, Mes, cool Guile libraries, and led to a bunch of new GNU packages such as a workflow language for scientific computing.
On the other hand, although Guix has a lot of regular contributors and is very active, Nix currently has more contributors than Guix. Guix is a younger project. The tendency to take bootstrapping problems very seriously means that sometimes difficult packages require more work. Oddly, Guix seems to attract more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with Scheme after watching the SICP lecture videos); it seems to be the other way around with Nix.
Having said all that: Nix and Guix are both implementations of functional package management. Both projects solve similar problems and both are active in the reproducible builds efforts. Solutions that were found by Nix devs sometimes make their way into Guix and vice versa. The projects are not competing with one another (there are orders of magnitudes more people out there who use neither Guix nor Nix than there are users of functional package managers, so there's no point in trying to get people who use Nix to switch to Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who invented functional package management and Nix) gave a talk on the future of Nix surrounded by Guix hackers --- there is no rivalry between these two projects.
----
Now to the last question: How usable are they? I've been using Guix (as a package manager and as an OS) since 2014 on all of my machines and I love it. I have written hundreds of package definitions both manually and with the help of "guix import", which generates them for me (even recursively). If you're okay with Lisp it's not painful at all. I have experience with RPM spec files and Arch PKGBUILDs and I love how declarative Guix package definitions are in comparison. For well-behaved projects that's great. For projects that reinvent build systems or come with custom build instructions or that assume unreasonable things about the target system things can get pretty gnarly, though.
Guix differs in that you don't use shell snippets to describe the installation steps. This can be confusing for people coming from other packaging systems, and it can be a little uncomfortable having to express things in Scheme instead. On the plus side you have access to a much more flexible language and don't have to mess with low-level shell. You can write procedures and reuse them across packages, or you can abstract the whole build process so that all that is ever needed is a declaration like `(build-system python-build-system)'.
(Things that suck: packaging NPM/nodejs things. Guix folks are really into building things from source, and there's a cultural mismatch with NPM folks. There are workarounds but there's no silver bullet.)
Dead Comment