I hate to say it, but while the substance of the article is useful, it disproves the title, in my opinion.
The title says that Nix is close to perfect, and then lays out a lot of shortcomings that take it far away from perfect.
I personally wish that there was a Nix that was well-documented, not so academic and elitist, and in general, had some empathy for users, especially for new users. In fact, lacking empathy for users alone makes something not close to perfect, in my opinion.
Also, the soft split that is mentioned makes me nervous. Why such a split? What makes flakes better enough that some people use them, but not better enough that others don’t?
This all might sound very negative, and if so, I apologize. I want Nix’s ideas to take off, so I actually feel discouraged about the whole thing.
Unpopular opinion here. The Nix docs are weird, but they are mostly fine. I usually don’t have any issue with them. The thing that usually gets me is the holes in my knowledge about how certain packaging technologies (both distro- and language-level ones) work and taking some of the things other distros do automatically for granted.
Here’s an example. You are playing in a Ubuntu-based distro, and you are writing some Python. You pip install some-dependency, import it, and everything is easy, right. Well, it felt easy because two months ago you apt install-ed a C dependency you forgot about, and that brought in a shared lib that your Python package uses. Or your pip install fetches a pre-built wheel that “just runs” (only on Ubuntu and few other distros, of course).
Nix is brutally honest and makes this shit obvious. Unfortunately, dealing with it is hard. [1] Fortunately, once you deal with all that, it tends to stay dealt with and doesn’t randomly break on other people’s computers.
Learning Nix has helped me learn Linux in ways I never originally suspected. It’s tons of fun (most of the time)!
[1] The rude awakening that a Python library can require a Fortran compiler is always fun to watch from the side. :)
The Nix docs are weird because they’re written for the wrong audience: people who want to learn Nix. I don’t care about Nix. Every moment I spend learning about Nix is just an inconvenience. Most Nix users are probably like that too. Users just want a packaging system that works, all of this discussion about Nix fundamentals is anti-documentation, things we need to skip to get to what we want: simple recipes for common tasks.
But Nix also has at least two fundamental technical issues and one practical issue that exacerbate the doc situation. The practical issue has to do with the name: it’s just a search disaster that Nix is three things (a distro, a language, and a package manager). On to the technical issues.
I can’t explore Nix because of the choice of a lazy language. Forcing values by printing them with builtins.trace is a minefield in Nix. Sometimes printing an object will result in it trying to create thousands of .drv files. Other times you find yourself printing one of the many circular objects that Nix uses.
In Haskell and C++ I get to look at types to figure out what kind of object I’ve got, in addition to the docs. In Scheme and Python I get to print values to explore any object. In Nix? I can do neither. I don’t get types and I don’t get to print objects at runtime easily. At least you can print .drv files to figure out that say, a package happens to have a lib output, and that’s what you need to depend on instead of the default out output.
There are almost no well-defined APIs within the Nix world.
Aside from derivations, it’s all ad-hoc. Different parts of the Nix ecosystem work completely differently to accomplish the same goals. So learning how to do something to C packages, doesn’t help you when you’re dealing with Python packages, and doesn’t help you when you’re dealing with Haskell packages (where there are two completely different ecosystems that are very easy for novices to confuse). Flakes add a bit of structure, but they’ve been unstable for 3 years now with no stability on the horizon.
I agree on both technical issues. Static types and type signatures in Nix would be especially amazing. I spend so much time wondering “what type does this have” when looking at nixpkgs code. :(
As for the fundamentals and anti-documentation features, I am not so sure. I think Nix is such a fundamentally different way of doing things, that you need to start somewhere. For example, I can’t give users a packaging script sprinkled with content SHA’s without explaining what those are and why we need them in the first place (It’s especially baffling when they sit right next to git commit SHA’s). The Nix pills guide has a good way of introducing the important concepts and maybe it can be shortened, so that people can go through most of the stuff they need in half an hour. I don’t know…
For a language that is the bastard child of Bash and ML, I would not consider it “academic”. The ugliness of the language is due in no small part to the affordances for real-world work.
As far as elitism…well, it’s a hard tool to use. It’s getting easier. It’s strange to me to expect that such powerful magic shouldn’t take some work to learn (if not master).
For a language that is the bastard child of Bash and ML, I would not consider it “academic”. The ugliness of the language is due in no small part to the affordances for real-world work.
I never said the language was academic. I don’t think it is. In fact, it’s less that the language is academic and more that the documentation and culture are.
As far as elitism…well, it’s a hard tool to use. It’s getting easier. It’s strange to me to expect that such powerful magic shouldn’t take some work to learn (if not master).
Power does not imply something must be hard to learn. That is a common misconception, but it’s not true.
As an example, consider Python. It’s not that hard to learn, yet it is enormously powerful. Or Ruby.
In fact, Ruby is a great example because even though it’s powerful, it is mostly approachable because of the care taken in helping it to be approachable, epitomized by _why’s Poignant Guide.
_why’s efforts worked because he made Ruby approachable with humor and by tying concepts of Ruby to what people already knew, even if he had to carefully lay out subtle differences. Those techniques, applied with care, would work for Nix too.
So the problem with Nix is that they use the power as an excuse to not put more effort into making it approachable, like _why did for Ruby. This, I think, is a side effect of the culture I mentioned above.
If someone wrote a Nix equivalent of _why’s Poignant Guide, playing to their own strengths as writers and not just trying to copy _why, I think Nix would have a massive uptake not long after.
In fact, please do write that guide, if you would like to.
I agree. It is some of the coolest Linux technology that is out there, but it is so hard to use. Both because its poor documentation and because of how different it is. When I used it, it felt like once a week I would try to do something not allowed/possible and then would have to go multiple pages deep on a thread somewhere to find multiple competing tools that claim to solve that problem best. I think I will try Nix the language on the next personal project I make that involves more than one language, but I haven’t had a chance to do that in a while.
I would love to try NixOS again sometime. Hopefully they will come out with better documentation and/or a “let me cheat just this once so I can continue working” feature.
Edit: I forgot to say, great article though! I enjoyed your perspective.
Keep in mind that the more familiar someone is with the subject the more issues they can talk about. I could go on for ages about problems with python, even though it is a perfect language for most of my use cases - It’s not a contradiction.
The post just concentrated on the negatives rather than positives - and there are some really cool things about nix. Especially if you have use cases where everything else seems to be worse (looking at you chef/puppet/ansible).
I’ve definitely had to figure out how to use a nixos module by directly looking at it source code on github to see how the module’s expected parameters get mapped to text in the native configuration file(s); then checking the documentation of the underlying program to see what thing was supposed to happen when those configuration items were set. The lack of documentation is a huge annoyance for using NixOS.
I don’t necessarily see the problem with using docker with NixOS, though. Some software projects distribute docker containers as the default way to run something, and NixOS’s ability to programatically specify a set of docker containers to run with specified environment variables and so on makes this as configurable as any other piece of software.
After using Nix (badly) for three years, I went back to Gentoo. It felt like coming home. Bash scripts, FHS and mutable filesystem: I’ve missed these things. Nix is great for doing things the right way if you already have a good idea what the right way is. But imo/e, Gentoo is better for messing around. And it turns out I value that highly.
It’s interesting that nix pills documentation is not mentioned. (Or was that just a part of the current documentation?) It’s got some good content, but it’s got a long way to go. It’s both very detailed and missing practical help. For example you learn 10 different ways to write a derivation - but there’s no “so in practice when you want a new package, do this” section. Almost every page contains “there’s no magic in this process” as well as “this magic function will…”. There’s a good start and I hope someone will edit it to be more useful and easy to read.
Like most of the Nix documentation, it really reads like it’s written by two people; the first, stating the problem in relatively common terms, is a technical person with no Nix experience; and the latter, a Nix expert, who offers up a totally impenetrable wall of nix-the-language and nix-the-experience jargon.
Flakes has a lot of differences between classic Nix and it makes a lot of techniques and configuration non-transferable between the two. It has effectively soft split the community between people that use flakes and people that don’t use flakes. I personally don’t use flakes because I haven’t seen good arguments as for why I should.
@cadey, I read this blog post by Eelco Dolstra in which he introduces Flakes and describes the problems it’s intended to solve. It seems to me like an argument as to why one should use Flakes. Do you disagree with his description of those problems, or of Flakes as the solution to them? If so, could you elaborate on why? I have never used Nix but am very interested in learning it, and have heard a bit about how some people like Flakes and some people don’t so much. I’d love to understand people’s perspectives on it better!
(Without reading the article, shame on me…) If the new user experience is so hard, is there a Stack Overflow-like site? The Stack Exchange Unix & Linux site seems to get about 2-3 nix questions a month, but I think that tag has the Rust problem where all the helpers are somewhere else. I imagine the Codidact/TopAnswers people could be persuaded to spin up a site for nix. There seems to be an active Discourse site (~137 “help” posts a month), but I still think a Q&A upvoteish site would be a better fit.
They share the issue that unlike apt where if you get an option wrong, some C code tells you that you got an option wrong, nix and guix just pass the wrong option down into interpreted code where you eventually get “string found where integer expected” or some such.
The difference is: guix’s error messages come from guile, a much more mature language runtime than nix.
I try nix once or twice a year, but I have to learn in all over again each time, and it’s rough.
I tried guix for the first time this past week, and even though I hit many issues, I found it much easier to diagnose and address them.
Full disclosure: I do have years of scheme/lisp experience, though none of it very recent. I have also done a non-trivial amount of Haskel/ocaml work. I like ocaml more than scheme. But I hate “programming” shell scripts.
In guix, I see much less occasion to drop down out of scheme to shell scripting.
I believe Nix is the thing that helps some future distro/packaging system be great by standing on its shoulders. It seems to me that Nix itself won’t be it. It’s just not simple and intuitive enough.
I hate to say it, but while the substance of the article is useful, it disproves the title, in my opinion.
The title says that Nix is close to perfect, and then lays out a lot of shortcomings that take it far away from perfect.
I personally wish that there was a Nix that was well-documented, not so academic and elitist, and in general, had some empathy for users, especially for new users. In fact, lacking empathy for users alone makes something not close to perfect, in my opinion.
Also, the soft split that is mentioned makes me nervous. Why such a split? What makes flakes better enough that some people use them, but not better enough that others don’t?
This all might sound very negative, and if so, I apologize. I want Nix’s ideas to take off, so I actually feel discouraged about the whole thing.
Unpopular opinion here. The Nix docs are weird, but they are mostly fine. I usually don’t have any issue with them. The thing that usually gets me is the holes in my knowledge about how certain packaging technologies (both distro- and language-level ones) work and taking some of the things other distros do automatically for granted.
Here’s an example. You are playing in a Ubuntu-based distro, and you are writing some Python. You
pip install some-dependency, import it, and everything is easy, right. Well, it felt easy because two months ago youapt install-ed a C dependency you forgot about, and that brought in a shared lib that your Python package uses. Or yourpip installfetches a pre-built wheel that “just runs” (only on Ubuntu and few other distros, of course).Nix is brutally honest and makes this shit obvious. Unfortunately, dealing with it is hard. [1] Fortunately, once you deal with all that, it tends to stay dealt with and doesn’t randomly break on other people’s computers.
Learning Nix has helped me learn Linux in ways I never originally suspected. It’s tons of fun (most of the time)!
[1] The rude awakening that a Python library can require a Fortran compiler is always fun to watch from the side. :)
The Nix docs are weird because they’re written for the wrong audience: people who want to learn Nix. I don’t care about Nix. Every moment I spend learning about Nix is just an inconvenience. Most Nix users are probably like that too. Users just want a packaging system that works, all of this discussion about Nix fundamentals is anti-documentation, things we need to skip to get to what we want: simple recipes for common tasks.
But Nix also has at least two fundamental technical issues and one practical issue that exacerbate the doc situation. The practical issue has to do with the name: it’s just a search disaster that Nix is three things (a distro, a language, and a package manager). On to the technical issues.
I can’t explore Nix because of the choice of a lazy language. Forcing values by printing them with builtins.trace is a minefield in Nix. Sometimes printing an object will result in it trying to create thousands of .drv files. Other times you find yourself printing one of the many circular objects that Nix uses.
In Haskell and C++ I get to look at types to figure out what kind of object I’ve got, in addition to the docs. In Scheme and Python I get to print values to explore any object. In Nix? I can do neither. I don’t get types and I don’t get to print objects at runtime easily. At least you can print .drv files to figure out that say, a package happens to have a lib output, and that’s what you need to depend on instead of the default out output.
There are almost no well-defined APIs within the Nix world.
Aside from derivations, it’s all ad-hoc. Different parts of the Nix ecosystem work completely differently to accomplish the same goals. So learning how to do something to C packages, doesn’t help you when you’re dealing with Python packages, and doesn’t help you when you’re dealing with Haskell packages (where there are two completely different ecosystems that are very easy for novices to confuse). Flakes add a bit of structure, but they’ve been unstable for 3 years now with no stability on the horizon.
I agree on both technical issues. Static types and type signatures in Nix would be especially amazing. I spend so much time wondering “what type does this have” when looking at nixpkgs code. :(
As for the fundamentals and anti-documentation features, I am not so sure. I think Nix is such a fundamentally different way of doing things, that you need to start somewhere. For example, I can’t give users a packaging script sprinkled with content SHA’s without explaining what those are and why we need them in the first place (It’s especially baffling when they sit right next to git commit SHA’s). The Nix pills guide has a good way of introducing the important concepts and maybe it can be shortened, so that people can go through most of the stuff they need in half an hour. I don’t know…
For a language that is the bastard child of Bash and ML, I would not consider it “academic”. The ugliness of the language is due in no small part to the affordances for real-world work.
As far as elitism…well, it’s a hard tool to use. It’s getting easier. It’s strange to me to expect that such powerful magic shouldn’t take some work to learn (if not master).
I never said the language was academic. I don’t think it is. In fact, it’s less that the language is academic and more that the documentation and culture are.
Power does not imply something must be hard to learn. That is a common misconception, but it’s not true.
As an example, consider Python. It’s not that hard to learn, yet it is enormously powerful. Or Ruby.
In fact, Ruby is a great example because even though it’s powerful, it is mostly approachable because of the care taken in helping it to be approachable, epitomized by _why’s Poignant Guide.
_why’s efforts worked because he made Ruby approachable with humor and by tying concepts of Ruby to what people already knew, even if he had to carefully lay out subtle differences. Those techniques, applied with care, would work for Nix too.
So the problem with Nix is that they use the power as an excuse to not put more effort into making it approachable, like _why did for Ruby. This, I think, is a side effect of the culture I mentioned above.
If someone wrote a Nix equivalent of _why’s Poignant Guide, playing to their own strengths as writers and not just trying to copy _why, I think Nix would have a massive uptake not long after.
In fact, please do write that guide, if you would like to.
If I had more spoons I’d definitely do that
I agree. It is some of the coolest Linux technology that is out there, but it is so hard to use. Both because its poor documentation and because of how different it is. When I used it, it felt like once a week I would try to do something not allowed/possible and then would have to go multiple pages deep on a thread somewhere to find multiple competing tools that claim to solve that problem best. I think I will try Nix the language on the next personal project I make that involves more than one language, but I haven’t had a chance to do that in a while.
I would love to try NixOS again sometime. Hopefully they will come out with better documentation and/or a “let me cheat just this once so I can continue working” feature.
Edit: I forgot to say, great article though! I enjoyed your perspective.
I have found the Guix documentation quite good, and the community very welcoming, for what it’s worth.
Keep in mind that the more familiar someone is with the subject the more issues they can talk about. I could go on for ages about problems with python, even though it is a perfect language for most of my use cases - It’s not a contradiction.
The post just concentrated on the negatives rather than positives - and there are some really cool things about nix. Especially if you have use cases where everything else seems to be worse (looking at you chef/puppet/ansible).
I wouldn’t feel discouraged if I were you. Nix’s community is nothing but growing. Most of these issues are warts, not dealbreakers.
makes me miss WORLDofPEACE. Didn’t know them, but they’re a good example of someone that can make anyone feel welcome IMO.
Of all the places to find a Stan Kelly reference, this I was not expecting.
Edit: also @cadey, I think you have a typo around “host colon porn thing”, unless this is targeting a very different audience.
I thought I fixed that, oops.
Null sweat!
Should be fixed now!
You’ve made my day, chummer.
The Stan Kelly parody is beautiful.
I’ve definitely had to figure out how to use a nixos module by directly looking at it source code on github to see how the module’s expected parameters get mapped to text in the native configuration file(s); then checking the documentation of the underlying program to see what thing was supposed to happen when those configuration items were set. The lack of documentation is a huge annoyance for using NixOS.
I don’t necessarily see the problem with using docker with NixOS, though. Some software projects distribute docker containers as the default way to run something, and NixOS’s ability to programatically specify a set of docker containers to run with specified environment variables and so on makes this as configurable as any other piece of software.
After using Nix (badly) for three years, I went back to Gentoo. It felt like coming home. Bash scripts, FHS and mutable filesystem: I’ve missed these things. Nix is great for doing things the right way if you already have a good idea what the right way is. But imo/e, Gentoo is better for messing around. And it turns out I value that highly.
It’s interesting that nix pills documentation is not mentioned. (Or was that just a part of the current documentation?) It’s got some good content, but it’s got a long way to go. It’s both very detailed and missing practical help. For example you learn 10 different ways to write a derivation - but there’s no “so in practice when you want a new package, do this” section. Almost every page contains “there’s no magic in this process” as well as “this magic function will…”. There’s a good start and I hope someone will edit it to be more useful and easy to read.
Like most of the Nix documentation, it really reads like it’s written by two people; the first, stating the problem in relatively common terms, is a technical person with no Nix experience; and the latter, a Nix expert, who offers up a totally impenetrable wall of nix-the-language and nix-the-experience jargon.
Thanks for taking the time to do this, Xe (@cadey)!
@cadey, I read this blog post by Eelco Dolstra in which he introduces Flakes and describes the problems it’s intended to solve. It seems to me like an argument as to why one should use Flakes. Do you disagree with his description of those problems, or of Flakes as the solution to them? If so, could you elaborate on why? I have never used Nix but am very interested in learning it, and have heard a bit about how some people like Flakes and some people don’t so much. I’d love to understand people’s perspectives on it better!
(Without reading the article, shame on me…) If the new user experience is so hard, is there a Stack Overflow-like site? The Stack Exchange Unix & Linux site seems to get about 2-3 nix questions a month, but I think that tag has the Rust problem where all the helpers are somewhere else. I imagine the Codidact/TopAnswers people could be persuaded to spin up a site for nix. There seems to be an active Discourse site (~137 “help” posts a month), but I still think a Q&A upvoteish site would be a better fit.
I’ve found people on the forums pretty helpful.
Do any of these shortcomings also exist in Guix?
Sort of…
They share the issue that unlike apt where if you get an option wrong, some C code tells you that you got an option wrong, nix and guix just pass the wrong option down into interpreted code where you eventually get “string found where integer expected” or some such.
The difference is: guix’s error messages come from guile, a much more mature language runtime than nix.
I try nix once or twice a year, but I have to learn in all over again each time, and it’s rough.
I tried guix for the first time this past week, and even though I hit many issues, I found it much easier to diagnose and address them.
Full disclosure: I do have years of scheme/lisp experience, though none of it very recent. I have also done a non-trivial amount of Haskel/ocaml work. I like ocaml more than scheme. But I hate “programming” shell scripts.
In guix, I see much less occasion to drop down out of scheme to shell scripting.
I believe Nix is the thing that helps some future distro/packaging system be great by standing on its shoulders. It seems to me that Nix itself won’t be it. It’s just not simple and intuitive enough.