Email or username:

Password:

Forgot your password?
Ludovic Courtès

Just gave a short introductory talk about Guix for the Software Sustainability SIG of the Netherlands eScience Center, following an introduction to Nix.

The audience doesn’t use either tool so far so now I’m curious to know if they’ll want to leave CONDA & co. for Guix or Nix!

12 comments
Ludovic Courtès

“Of Nix and Guix, which has the steepest learning curve?”, someone asked.

I replied that from the start we tried hard to make Guix approachable, more than the Nix I contributed to back then, also adding facilities like command-line transformation options… but that I’m biased.

I wonder what an objective answer would be. Anyone? :-)

Janneke

@civodul
I think it's a pretty silly question.

Why invest in learning the easiest of the two (by some subjective assesment), if the other one would better suit your needs?

Ludovic Courtès

@janneke Someone used to CONDA, apt, and whatnot may view Nix and Guix, from a distance, as “similar”.

It’s only when getting closer that one starts to appreciate the differences.

The first difference one might notice is ease of use (or perceived ease of use).

Raito Bezarius

@civodul @janneke I think it has also a lot to do with your prior exposure to functional programming, I like to think that Nixlang is more a very simple barebone Haskell whereas Guix enjoys Lispy ecosystem.

Also, I think learning Guix or Nix is a very open-ended question :) — I suppose that people don't think of learning everything there is to learn but learning towards objective X. For example, not everyone has to learn about the bootstrap machinery of any tool they use.

McSinyx

Wouldn’t claim it to be objective, @civodul, but I don’t think the tooling could be considered by itself alone. I use nix in my software engineering research on a workstation running guix system solely because most dependencies are already in nixpkgs. While I do prefer guix’s insistence on bootstrapping, devendoring and compiling from source, time and energy does not allow me go an extra mile and declare the missing packages.

Documentation of nix libraries are also more available, and perhaps I don’t know guix enough but overriding and overloading packages on nix requires repeating myself less often.

Wouldn’t claim it to be objective, @civodul, but I don’t think the tooling could be considered by itself alone. I use nix in my software engineering research on a workstation running guix system solely because most dependencies are already in nixpkgs. While I do prefer guix’s insistence on bootstrapping, devendoring and compiling from source, time and energy does not allow me go an extra mile and declare the missing packages.

nmeum

@civodul Having experimented with both Nix and Guix recently, I personally feel like Guix is more approachable because it uses a Scheme EDSL instead of inventing its own language. However, I also had prior experience with Scheme which likely gave me a head start on Guix. Probably hard to come up with an “objective answer” though…

Justin

@nmeum @civodul

I've also had a better time learning Guix.

I think Guix is more approachable than Nix - not only because it's based on a programming language with simpler semantics - but because they've put more time into their documentation and included more tools into into the default ecosystem. IE `guix home`.

Justin

@nmeum @civodul

However, I feel that Nix has focused on meeting the developer where they are at. We can see this because I think they differ in the developer experience in two important ways. They've leaned heavily into `devShells` with having various shell hooks and being able to set environment variables. And they support a wider array of systems. I like working on MacOS, so being able to use Nix to _easily_ manage my dev environments is what ultimately made me side with Nix.

Justin

@nmeum @civodul

The devShell enhancements might exist in Guix; I just never found it when I was playing with it.

The other thing that I think Guix could beat Nix is autocomplete. I think Guix could more easily support systems like LSP, making writing these systems much easier.

Robby

@civodul I’m also biased because I’m someone who follows you because of your work on Guix, but FWIW I started with Nix first, and then switched away because I found it to be harder to use than it was worth to me. I later found Guix, and it has been much easier for me to use.

:female_presenting_nipple:

@civodul There are multiple things to consider here: previous experience with lisps or haskell can sway one easily. Having programming experience too: imo Nix is easier to grasp, because its a more limited language. But if you're familiar with lisps, then Nix will suddenly be at a major disadvantage.

Reliance on (or familiarity with) systemd likewise (if you extensively use systemd, then learning guix will involve learning shepherd too).

Then there are the docs. Nix has a problem there, because of flakes: the official docs barely talk about them, yet a large part of the community embraces them. This makes figuring Nix out a lot harder.

Iow which one is the easier depends a lot on circumstances.

@civodul There are multiple things to consider here: previous experience with lisps or haskell can sway one easily. Having programming experience too: imo Nix is easier to grasp, because its a more limited language. But if you're familiar with lisps, then Nix will suddenly be at a major disadvantage.

Christina Sørensen

@civodul with no hard evidence to back this up, but as a former guix user who now use nix, I'd say that learning nix has been hardest. Buuuuuuuuut if we include GNU shepherd I think it evens out.

Go Up