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 open sourced our Nix dev environment tool (Devbox), and wrote a bit about why we switched here: https://www.jetpack.io/blog/devbox-turn-a-1000-container-scr...

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.

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.

No need to use containers too, which bring cognitive/workflow overhead.

If you're asking if installing/running software with Nix requires containers like Docker does: no, it does not.

> At least with Docker you can get something useful within 2 minutes

  % nix shell 'nixpkgs#ruby' -c irb
  irb(main):001:0> puts "Hello, world!"
  Hello, world!
  => nil
  irb(main):002:0>

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.

Nope.

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.

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.

Whereas Nix keeps binaries around longer, but also includes the ability to automatically and reproducibly build from source.

More appropriate comparisons would be: - NixOS and Ubuntu - nix and apt/homebrew

But I'm yet to use NixOS, so i don't know what it's downsides are..