I think the main difference is that Guix uses an actual language and writing things for it seems pretty reasonable, while Nix language is frustrating to work with and look at. There are probably hundreds of functions in nixpkgs that would make your life easy, but only 3.5 people know about them or how to use them.
Guix is definitely a cleaner implementation (coherent cli tooling, way better manual, not a custom, oddball language, ...).
But:
* if Nix is already very niche, Guix is the niche of a niche. The ecosystem is tiny in comparison.
* The Nix interpreter isn't exactly fast, but Guix (with it's scheme) was significantly worse for me, even in relatively small tests
* The hard stance on open source requirements is understandable, given the projects origin, but it will severely hinder adoption. No, I don't want to package every commercial app I need myself. nixpkgs has almost everything.
I found Guix a lot more organised. Most package code is very simple, and the toolchain is also quite elegant. Hopefully the latter will be addressed by the new nix interface.
I’m all in on Nix (the package manager) today and use it across multiple Linux and Mac machines to handle my configs and most of my app installs.
That said, I still find nix difficult to understand and learn, and when I get stuck on something it seems extremely frustrating to unstick myself.
I would love to try Guix, mostly because I think building on an existing language would have solved many of my issues with nix, but the whole point for me is that I want a stable config across all of my platforms; the “non free” restrictions guix poses has gated me from it.
When I got into Nix and Guix I tried both and I leaned towards Guix because "it's scheme" but ended up sticking to Nix because of maturity, Darwing support and it being way more performant.
In the end I realized that I actually prefer Nix as a language. I like that it's a very simple and limited language, with, for example, no way of performing side-effects. It is tailored towards it's purpose and, while not perfect, it does the job well.
As other point out, Nixpkgs and the Nix toolchain in general just uses very weird names for everything, plus the docs. That's the difficult bit. It's slightly improving over time.
As someone coming from the computing side of things, I found nix to be quite difficult to grok enough to write a package spec, and guix was pretty close, at least in part because of the whole "packages are just side-effects of a functional programming language" idea. At least nix also suffers from a lot of "magic"; if you're trying to package, say, an autotools package then the work's done for you - and that's great, right up until you try to package something that doesn't fit into the existing patterns and you're in for a world of hurt.
Well this is enough to put anyone off Nix. Such a shame because the abstract idea is obviously a good one. But every time Nix/NixOS comes up the story is the same.
I generally don't like to talk about other projects negatively, because I don't think that Nix and Guix should compete. They are different takes on the same concept. But as I'm very familiar with Guix and have occasionally looked at how they deal with some of the packaging problems I worked on in Guix I can say that the
Nix colleagues are often punting on problems instead of solving them. Let me give you a few examples.
In Nixpkgs there are quite a few generated packages, some of which cannot be built. I'm maintaining R packages (from CRAN and Bioconductor) in Guix and I see that the equivalent packages in Nixpkgs do not accommodate some of their quirks, so they cannot actually be built.
Another example where Nixpkgs does not build packages from source is TeX Live. The SVN repository of TeX Live contains countless generated files, and all of the TeX Live packages in Nixpkgs merely copy the generated files from SVN instead of building them from source.
Java packages in Nixpkgs often seem to include pre-built jars whereas in Guix we're going to great lengths to build everything from source. This comes at a cost, of course: Guix has fever Java packages because of that, but those that it has are actually built from source.
Of course, I'm biased towards Guix, but I must say that I'm very fond of the level of integration that Guix achieves. When I look at Nix I see a bunch of seemingly separately developed tools that are written in a mix of languages (with Shell code being rather common). In Guix all tools are written in Scheme, use the same API, behave similarly, etc. It just feels much more polished to me.
That said, there is no animosity between these communities, and I think we would all be better off avoiding the mental pitfall of competition; we work on the same problems with different values and thus our approach differs. This leads to diversity rather than duplication of work.
Have you looked into Guix? In some ways it's a bit simpler and cleaner because it is a much more recent effort and Scheme is somewhat easier. It might help with the learning process in case you disliked Nix. GuixSD does have some other drawbacks. I'm personally running NixOS but both are very cool.
Nix certainly has a steep curve, but simple things are not that hard. I got committed to migrate to Nix one Monday. I spent the whole morning reading about it. In the afternoon, my workstation was already up and running. On the same evening, I packaged two exotic things I need which weren't on NixPkgs. Next day, I fixed my favorite window manager, which was broken on NixPkgs. I maintain all these on NixPkgs now.
Complicated things are not that easy, and I would not have been able to do all this if I had encountered non-trivial issues in the process. I also totally understand that the learning curve is steep. Nix has too much legacy stuff and cruft built in. There's the classic Nix command, Nix 2.0 and Nix flakes. They are all coexisting and not very well documented. Nix needs more manpower, funding and tooling.
With that said, declarative stuff is poised to be harder for non-trivial stuff. Just like Haskell is harder than C, NixOS is harder than ArchLinux or Alpine. I still very much find it worth the effort for simple workflows. I can now update remote machines without fearing breakdowns and state is very explicit.
If I could trouble you for the common discourse here, would you mind summarizing why one may prefer to use Guix in the place of Nix? They seem to be based on the very same ideas and Guix even admits to being inspired by Nix.
The problem I have with Nix (and Guix) is that you're shit out of luck if you need it to work together with some network based package manager or existing project that someone didn't add to it yet.
It gets really complicated really fast, and things that "just work" with other packages managers and projects, because they are opinionated and linux-y, most of the time don't work well with Nix or have to be shoehorned into it.
It always feels like you're fighting against everything to get things into Nix that just weren't meant to be.
The thing is, they are competing for package maintainers and users. A Nix package can't be natively used by Guix, and vice-versa, so a package have to be written for both.
Initially, I really wanted to use Guix over Nix, but Nix is more mature with more packages, maintainers, and features.
Last I checked, for example, there was no equivalent of a channel or overlay in Guix. Their npm importer was also not released, whereas Nix has a very usable node2nix.
Having done virtually no functional programming, learning Guile Scheme was also a barrier to me, but the Nix expression language felt a lot more natural for whatever reason.
It's unfortunate - I'm very interested in the work in reproducible builds and substitutions Guix has done, maybe it'll take off at some point or those features will be integrated into NixOS.
Well, Guix started as Nix with established language, and that didn't really made it better.
The Nix language is functional and lazily evaluated, it closely matches how Nix works builds packages, which basically makes it less verbose.
Even if they used python (or python like language like starlark), and then proceed to build an abstractions on top of it, barely documenting the function. Leaving old ones with the new ones, you would still be confused and frustrated needing to look at the source code.
Nix uses it's own specific language. Guix uses Schema.
Last time I checked Nix its interface was scattered into a bunch of tools. Nix is pretty neat though but not without weaknesses.
Guix on the other hand provides those, but is far from what nixpkgs offers in terms of number and actuality of pkgs.
reply