Notes on Nix
They helped me. Maybe they will help you.
I have spent the last 5 years telling myself “Someday I’m going to sit down and figure out what Nix actually is.”
So I finally used the US holiday weekend to look into it.
Here is what I learned:
Nix is a set of tools for helping you configure your software environment exactly the same way every time. That is what it is.
However…
The ideas behind Nix are advanced, so much so that it started life as a guy named Eelco Dolstra’s Ph.D. dissertation1. It has a learning curve that goes beyond “steep” and does a full loop-the-loop, like one of those fairground rides that unfolds off the back of a truck. The biggest reason Nix is still a niche technology, rather than the One True Way that we manage our software packages, is that most professional software engineers who take one look at Nix say “Dear God, no. And also, what is it? Please make it stop.” For them, the cure (reshaping their brains to speak Nix) is worse than the disease.
But those who persevere—interesting software shops like Replit and Shopify—choose Nix for a good reason. Because there is a disease. And it lies in wait for us all.
THE DISEASE
The disease is software itself. Specifically, software dependencies.
All the little packages that your code imports, plus all the little packages that THEY import, right down to things like the C compiler included with your operating system (OS)…
The metadata used to compile your system libraries…
The minor version of your operating system…
All those things your code needs to run are dependencies and collectively they are known as your software environment.
(Sometimes Nix people prefer to say “the closure of your dependencies” which is a FUNCTIONAL PROGRAMMING way of saying “the whole universe of everything that you depend on” but FUNCTIONAL PROGRAMMING is one of those things a lot of us don’t feel comfortable thinking about and so we are not going to think about it.)
Any time you deploy software — to paraphrase our buddy Eelco, that’s when you move a program from computer A to computer B and it still works when it gets there—you are betting that the software environment on computer B will interact with your code in the same way that it did on computer A.
Historically, this has been a sucker’s bet. Linux uses what is called “dynamic linking” which means that the system libraries you depend on can change out from under you when your OS updates. The default package managers for your Linux distros, like yum and apt-get, like to install a single version of your dependencies GLOBALLY which means that if different apps require different versions then haha good luck.
If you have ever tried to update Python on your Macbook, you know how easy it is to end up with a nasty dirty developer environment full of broken packages of unknown origin.
What we all want is REPRODUCIBILITY which means I want to specify EXACTLY what dependencies my software environment needs and I want them to deploy EXACTLY THE SAME WAY every time on every machine. That is the problem Nix is trying to solve.
And at the time Eelco was writing his dissertation in the early 2000s there was not really a great way to ensure this.
THE NIX CURE
The cure was functional programming!
This is why so many people get hung up on Nix, because functional programming hurts our brains. But the big concept is not hard to understand:
Nix wants to help you build your software “without side effects” - that is, without changing other things in your system that you didn’t specify. This is sometimes referred to as a PURE FUNCTIONAL approach. Again, all it means is that what you put in (the description of what your environment should look like) is exactly what you get out.
Nix uses several pieces to make this happen, including among others:
A little mini-programming language that helps you say what packages you want
A package manager (a thing that downloads the packages you want and saves them in a unique location)
A special build of Linux called “NixOS” that you can put your packages in if you want to have an end-to-end Nixified software environment
A tricky part is that people might refer to all of these things, or some of them, or just one at a time, as “Nix”. And that is why when you ask ten different Nix gurus to define “Nix” you will get ten different answers, like blind men describing an elephant.
But don’t be dazzled. Nix is a set of tools for helping you configure your software environment exactly the same way every time. That is what it is.
THE INSUFFICIENT CURE
Docker. Docker is the insufficient cure to the software dependency disease.
If you want to prickle the hackles on a Nix devotee, say “Why don’t you just use Docker?”
The Nix devotee will say that Docker containers do not give you truly reproducible builds in the way that Nix does. There are quite a few things that can change out from under you, even with a “pinned” Docker image. Plus, stacking Docker images on top of each other quickly leads to duplicated packages, whereas Nix hashes references to everything in the environment to avoid duplication.
The Nix devotee will also say that Dockerfiles are IMPERATIVE and Nix is DECLARATIVE. A Dockerfile says “run this command and then that command, in that order, to build the environment.” A Nix configuration says “Here is what the environment is supposed to look like, go make it so.”
That said, you can actually use Nix to generate Docker images and lots of people do.
I asked ChatGPT to give me an analogy comparing Nix and Docker, and it said if your software is a sandwich, Nix is like a recipe and Docker is like a lunchbox.
That is sufficiently insane that I’m going to roll with it.
THE TRAGEDY OF NIX
The tragedy of Nix is that the documentation is famously poor, the mini-language is hard to learn (it’s functional, natch), and over time other solutions such as Docker (for shipping reproducible environments) and Alpine Linux (for minimal OS builds) sprang up that were “good enough” for a lot of use cases.
That said, these days people are developing their software in cloud environments that need special automation, and the overall increase in sophistication of software infrastructure teams suggests that maybe Nix has brighter days ahead. There’s really nothing else out there quite like it.
If you want to get into the HOW of Nix, I recommend these Zero to Nix tutorials.
Just for fun
I drew this cartoon to help promote the fireside chat I’m doing with Rubrik next week. See you there!
The dissertation is actually wildly readable and informative. It is a Good Tech Thing. Bring it with you on a plane sometime.