you know how if you edit the first line of a 50 line docker file you gotta sit there forever to rerun the entire build? You don't have that issue with Nix.
You know how a Docker file barely has any structure, leading to a lot of bashisms to try and script certain behaviors? Nix doesn't have that issue.
NixOS is an OS you can configure with Nix. A lot less "OK so edit these files to try and configure something, then reboot", a lot more "configure this data structure, then reboot". Makes your system configuration mostly be in the same place, as NixOS will distribute these changes across the file system as needed to get things working. It's pretty nice!
Overall... it ends up being a bit easier to document why you're doing something in a Nix file relative to a Dockerfile, and caching and the like works much more smartly (lots less "move all this stuff to the top/bottom for caching reasons" you might do in a Dockerfile)
("Nix" here means "nix + nixpkgs", which is important since lots of nix-ism are basically downstream of how nixpkgs is written and the patterns used there)
We switched to using Nix at our startup because the rebuild time, reproducibility, and performance of Docker (especially on MacOS) were really slowing us down. Building and starting our dev container could take several minutes if we busted Docker's layer cache, but with Nix we never had to worry about that.
NixOS is also a declarative build of the entire machine as opposed to just a container also, so it's totally normal to have a NixOS build with multimedia apps, games, etc.
To me, Docker is for building an entire environment for a single app to run in, whereas NixOS is for building an environment that runs multiple apps. Like a microservice vs a desktop machine.
> so it's totally normal to have a NixOS build with multimedia apps, games, etc
Every time I try NixOS on a desktop with anything more complex than setting a couple flags (writing some derivations to work around the broken software, managing my dotfiles etc), my configuration ends up as an unholy mix of weird Nix trickery, FHS paths in a non-FHS environment, and foreign config includes. It's like writing (programming) your Emacs config by patching the existing one with a Python script, for twice the fun. Of course it also needs to be versioned and documented to keep track of it, otherwise what's the point.
I can't help but think that the Arch approach (make the system management transparent, close and personal, and ignore the burning trashcan) is infinitely easier for personal usage than the Nix approach (describe everything with an additional layer of indirection). It's probably the opposite for huge deployments, of course.
That actually makes me feel little better. I spent a few weekends trying to get a little raspberry pi SNES emulationstation on NixOS going and it turned out to be a total waste. I quickly found myself deep into scripting custom configs and questioning whether the packages I was using actually work. Reproducible != Just works
I assumed I was just a dummy for not getting it to work because there are tons of peoples' flakes on Github with their entire desktop environment declared. That's what gave me the impression that this was totally normal. It's super cool and impressive but I just haven't grokked reading Nix yet.
Docker is not reproducible, you just apt-get install what you want hoping that the RUN commands get you a version that is still compatible with your software and doesn't break anything. With NixOS, you can pin the specific hash of every software, and you don't need the entire Ubuntu 20.04 in a container to deploy a webapp.
How does apt-get install handle the following scenario?
You need the following software:
- You need the latest release of Erlang for your app
- A database (like Riak), whicn in turn happens to need an older version of Erlang
- The new Erlang needs the latest libopenssl
- The old Erlang needs an old v1.x libopenssl
- You used some open source software written in C++, so you need libstdc++
- Some of your own C++ code has exposed a bug in libstdc++, so you need yet another libstdc++ with your patches, but just for that software
- Etc
How does apt-get install allow you to have multiple versions of a given dynamic library (with the same SONAME) and multiple binaries (erl, clang, etc) installed at the same time?
The answer: it doesn't.
Nix has no problem handling everything I described above, and it handles it easily.
So, yes, you can pin versions with apt-get install, but you're out of luck if any of those packages have any transitive dependencies with different versions.
Also, the pinning guarantees are higher with nix: you can be guaranteed that your packages and their transitive dependencies are byte-for-byte identical, every time. Pinning end-to-end across all packages (and every transitive dependency thereof) is not a normal, happy-path thing to do in apt, so you would be hard pressed to find anyone that does that, given how onerous that would be -- whereas it's trivial in Nix.
What's the model of the pinning? Is it an arbitrary semver? Is it a sha256 calculated by the content of the package (Content Addressed)? Is it a checksum calculated from all the inputs that were used to create the package install spec (Input Addressed)?
At best, you can do something like this: apt-get install gparted=0.16.1-1
That handles the semver case, but that doesn't address the rest of the "all of the above":
- sha256 calculated by the content of the package (Content Addressed)
- checksum calculated from all the inputs that were used to create the package install spec (Input Addressed)
> Nix isn’t the first package manager to do something unique.
Sure. But it is the first package manager to do the above unique things. After all, the reason for Nix's existence is just that: no other package manager before it has done what it does.
Better composability and abstraction, see for example how you can configure a process in https://devenv.sh/services/ that has first-class support for development environments using Nix.
No need to use containers too, which bring cognitive/workflow overhead.
That took me about 5 seconds to type out, and now I'm in an IRB REPL slinging Ruby code, despite having never installed Ruby prior to running that command. Add another 5 seconds for nix to fetch the necessary files (which are then cached locally, so a second `nix shell` invocation will be immediate) and we're sitting at roughly 10 seconds end-to-end.
If it takes 2 whole minutes to use Docker, Docker must be pretty bad. I guess vintage things have their appeal, but apart from that I don't see why people would be so attached to such archaic, inferior technology.
You can build containers with nix, but they’re completely different. One is an operating system built around a package manager and the other is a containerization tool.
More appropriate comparisons would be:
- NixOS and Ubuntu
- nix and apt/homebrew
