> In short, GNU Guix is both a package manager you can use in any distro and a full-fledged GNU/Linux distribution, that is modern and advanced
Why not just use Nix, which is more battle tested?
Why not just use Nix, which is more battle tested?
Guix has an excellent CLI and awesome docs. It's stable and plenty usable. All being in one, high-level language like Scheme makes it seem really easy to hack on, and I think that's part of why its CLI is so good already.
Nix is faster, it supports macOS, and its package collection is much bigger because it's older. But Guix seems great to me, too! If you think you might like it, try it.
There are quite a few popular channels, such as non-guix (with things like vanilla Linux), guix-science, guix-past, etc.
As a maintainer of R packages in Guix I'd also like to point out that many R packages in Nix actually need more work to build them, so the number of packages in Nix is rather inflated. Guix also goes to great lengths to actually build things completely from source, such as Java packages, or to minify JavaScript from source files.
Nix flakes are kind of a lot of things: a version pinning system, the switch to pure evaluation mode by default (which impacts caching in a good way but makes configuration slightly more annoying), a distribution mechanism for code written in Nixlang, and a collection of Nixlang schemas which enable a richer command line experience (that, e.g., power the new `nix run` command). It's not clear how many of those functions Nix flakes will retain in its final form.
There's no singular feature that attempts all that in Guix as far as I know, and I don't know the general technical story for evaluation caching with Guix. But Guix does have an integrated, first-party form of package pinning. Where Nix flakes replaces the old 'channel' system, Guix has a richer notion of channels which support pinning in normal Guix expressions.
(In Nix, channels are an output that have a certain structure and get managed in a certain way via fhe nix-channel command to manage them— they're like another type of Nix profile. In Guix, channels are defined by the user directly in Scheme code, just like the rest of their configuratiom, which is more similar to how Nix flake inputs are defined than to Nix channels.)
I've never used Guix channels in anger, so I can't tell you how nice that notion of version pinning is to use.
https://guix.gnu.org/manual/en/html_node/Replicating-Guix.ht...
And while nix may be battle tested that doesn’t translate to a good experience, the learning curve is high and the documentation while plentiful is not really good or helpful to beginners. Plus the entire thing is in flux right now between flakes, home-manager, and a desire to kill nix-env.
If I read this on any other website I’d assume it’s sarcasm. Only on HN, folks.
If you're a long-time lisper interested in the ideas embodied by nix/guix, that alone is a lot of points for guix.
Oh don't get me wrong, I'm not saying guix is better (I have absolutely no idea), just that the experience with nix is extremely rough so nix being a bit more popular is not necessarily that much of an edge (or one at all).
> I like Guix as package manager, but their docs can definitely be improved with loads of examples and tutorials.
In fairness I'll say that especially if you're a long term user it is very easy to be blind to the early user experience. Sadly most projects don't push new users towards really reporting their experience or even contributing to the docs, but if you have the time and inclination to do so I'm quite convinced your experience would be extremely valuable to those who'll come after you, even if the project doesn't necessarily value them that much (but even then it can be useful as evidence of issues with the early experience / uptake, and possibly efforts to rectify them later on).
It's also useful on a personal level, because memory is a fickle thing and a year from now you may not even remember your struggles.
I've not yet had the energy or patience to learn the TexInfo format, which is a standard for GNU projects. But if anyone wants to put what I have in the Guix docs, even as merely an example or tutorial, I wont mind.
The issue here isn't just that the documentation is lacking, but that Guix wants to have everything done in Scheme, so you often run into the issue of having to translate code you already have running in Bash into whatever Scheme equivalent Guix wants.
This is my big gripe with Nix. There are so many things that are almost ready, or almost integrated, and advanced users are typically already using them. It makes it feel like next year will always be a better time to recommend Nix to newbies.
And a lot of the more ambitious contributions to Nix and Nixpkgs that are really, really exciting as a user tend to sit in pull request limbo for a very long time, sometimes dying on the vine. Guix doesn't seem to have that problem yet, but I don't follow it as closely.
It's painful to feel sort of totally married to it but also like I can't whole-heartedly recommend picking it up to most people I know who might enjoy it once they got going.
I haven’t used NixOS though, which could make things a bit different.