Guix is strange and unconventional in the same fundamental way as Nix, namely that each package is installed to its own, immutable, quasi-content-addressed prefix. This is because that design decision is what gives both package managers their superpowers.
If you are already a Scheme user, you may find Guix more accessible for you. If you are not a C++ programmer, you may find hacking on the package manager itself easier with Guix.
In terms of the CLI interface, Guix really shines here. Guix also has a more centralized approach to documentation, which you may find helpful.
Beyond the surface-level language differences, Guix has gone with different abstractions than Nix in some key areas, and has some features that Nix lacks. One big one is that GuixSD uses a different model for defining the options that can be used to configure the system. Guix's approach¹ is more explicit, and features some provenance tracking for configured options— it can draw a graph for you showing where each setting on your system came from.
Guix also takes a different approach to pinning package versions and defining repositories of source packages, and its conventions for doing those things are more settled than their equivalents and alternatives in the Nix world.
Guix also supports a feature called 'grafts'² that allows you to avoid rebuilding the world in case of things like mission-critical security updates to glibc. This is a really cool and useful feature!
I'm sure there are other things that more serious Guix users can better highlight than this dilettante. :)
The Guix blog is really excellent! I strongly recommend it for getting a sense of what problems Guix tries to solve and how it sometimes approaches them differently than Nix does.
I tried and bounced off Nix on other systems, and I'm now running nixOS on my personal laptop (which is a secondary device).
I think there's absolutely room to solve the same set of problems better than Nix does:
1. The number 1 problem for me has been documentation of nixpkgs. Nix lang is a bit funky but even if I was writing python the problem is that you're writing code to assign magic objects to magic variables and the only way to find the right ones is to read the nixpkgs source (and given the size of all-packages.nix and the limit of github's web viewer, maintain a local checkout).
2. Second place goes to the flake/non-flake divide where the nix community generally implies flakes are better but apart from the nix cli detailed docs, most things refuse to acknowledge its existence in the official docs.
3. Portability between macOS and Linux, where flakes actually make the situation worse as the root config is now system specific.
4. Tools like flakes, niv, the suggested way to write a shell.nix all want you to handle full commit hashes directly which is kinda unergonomic.
None of these are inherent to the problem space. If I was to keep writing the list, maybe around 9 and 10 are the things around nixlang being a funky language or /nix directory that the "you just need to understand functional languages/content addressable stores" discussion seems to think are the top ones.
Agreed on points 1 and 2. I think 3 is basically solvable for Nix, and it's easy to paper over with a Nix library for now.
Re: 4, Flakes do let you define inputs in terms of Git tags and branches and then have the computer resolve those to commit hashes for you, which is good.
Overall, I agree that it's not fair to think of package managers that work in the same basic paradigm as Nix as mere also-rans or clones. There's a lot of room to meaningfully experiment in the space and Guix's developers have proven thoughtful about where they want to differ in technical and ergonomic matters.
If you are already a Scheme user, you may find Guix more accessible for you. If you are not a C++ programmer, you may find hacking on the package manager itself easier with Guix.
In terms of the CLI interface, Guix really shines here. Guix also has a more centralized approach to documentation, which you may find helpful.
Beyond the surface-level language differences, Guix has gone with different abstractions than Nix in some key areas, and has some features that Nix lacks. One big one is that GuixSD uses a different model for defining the options that can be used to configure the system. Guix's approach¹ is more explicit, and features some provenance tracking for configured options— it can draw a graph for you showing where each setting on your system came from.
Guix also takes a different approach to pinning package versions and defining repositories of source packages, and its conventions for doing those things are more settled than their equivalents and alternatives in the Nix world.
Guix also supports a feature called 'grafts'² that allows you to avoid rebuilding the world in case of things like mission-critical security updates to glibc. This is a really cool and useful feature!
I'm sure there are other things that more serious Guix users can better highlight than this dilettante. :)
The Guix blog is really excellent! I strongly recommend it for getting a sense of what problems Guix tries to solve and how it sometimes approaches them differently than Nix does.
--
1: https://guix.gnu.org/manual/en/html_node/Defining-Services.h...
2: https://guix.gnu.org/blog/2020/grafts-continued/