20 years of Nix

I wonder if the corporate backing behind Docker has anything to do with Nix being adopted less. There’s a lot of overlap between Nix and Docker, and Docker had major corporate guns behind it from early on. Reproducibility as you mentioned, is easily achieved with Docker, and there is no need to learn the Nix ecosystem.

Personally, I want to learn Nix, but Ive never forced myself to do it because it’s so much easier to make a Docker image do what I want. Nix is the pinnacle of a reproducible environment that doesn’t randomly break, but Docker is 80% of the way there and much easier.

It’s like comparing trucks (Docker) with planes (Nix) for logistics. I can pay out the wazoo for a plane to get my package there over night, or I can pay a small fraction to wait a few days.

We find it immensely useful to program our packages (technically, "derivations"):

It's trivial to combine multiple packages into one, e.g. via the 'nixpkgs.buildEnv' function. We use this to define a package called 'tools', containing shells, linters, differs, VCS, converters, data processors, etc. Our devs only need to install one package; and if they find something useful enough to share with the team, they can add it to that 'tools' package.

This approach is also modular/compositional: we define a 'minimal-tools' package containing bash, coreutils, git, diffutils, sed, grep, archivers, compressors, etc. which is enough for most shell scripts. Our 'tools' package is defined using that 'minimal-tools' package, plus a bunch of more-interactive tools like process monitors, download managers, etc. The reason we made this modular is so each of our projects can include that 'minimal-tools' package in their development environments, alongside project-specific tooling like interpreters (NodeJS, Python, JVM, etc.), compilers, code formatters, etc. (depending on the whole 'tools' package felt like bloat, and was easy to avoid)

(Outside of work, my personal NixOS config takes this even further; defining different packages for e.g. media tools, development tools, document tools, audio tools, etc. and splitting those into separate packages for gui/cli tools. That's not particularly "useful in practice"; I just like to keep my system config organised!)

Another very common way of programming with packages is to override their definitions. For example, we override the whole of Nixpkgs to use the 'jre11_headless' JVM. This is done by the following 'overlay' function (all of the dependency-propagation happens automatically, since Nixpkgs uses laziness):

  self: super: {
    jre = super.adoptopenjdk-jre-hotspot-bin-11;
    jre_headless = self.jdk;
    jdk = super.jdk11_headless;
  }

Overriding is also useful for individual packages, e.g. if we want to alter something deep down a dependency chain. It's also useful for applying patches or running a "fixup" script to the source, without having to e.g. fork a git repo.

> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors.

Heh, that reminds me of installing NixOS back around 2014. I didn't have any way to physically boot off the install CD; so I ran it in qemu, using my real /dev/sda as the "virtual" hard drive (which I'd already partitioned). Thankfully there was no interference with the host system (Trisquel).

I'm still using (and evolved version of) the same NixOS config to this day; it still contains the following comment ( https://github.com/Warbo/nix-config/blob/master/nixos/machin... ):

  trace "FIXME: Which modules are artefacts of using QEMU to install?"

The problem with Nix is that I still have to start with a Linux system--so I still need Docker, Terraform, something to give me a stable base for Nix to work against.

At that point--why should I add Nix to the mess since I still need those other things anyway?

> Docker serves the basic functionality of a container as well as any other

I disagree. We've had multiple production outages caused by the Docker daemon misbehaving (usually causing us to run out of disk space). It also makes operations far more difficult than necessary; e.g. want to copy a .tar.gz file to AWS? Sorry, Docker's gonna insert itself in the workflow, and over-complicate the authentication[1]. Instead, I have a script which runs [2] in a loop; much easier!

> The workflows that forced you to migrate away from it are more complicated, I’m sure, than a procedurally defined dev environment.

The container I mentioned literally just runs `java -jar` with a pre-built .jar file. Nothing fancy. Still, I have no idea what it's running, since Docker allows mutable tags, and there's no reference to a version number, let alone a git revision.

> Your comment further pushes me away from Nix, really, even without mentioning it. It makes it seem even more like a tool that’s not for me

I wasn't talking about Nix, I was talking about Docker. They're very different tools (Docker manages running processes/containers; Nix describes the contents of files). I just really hate Docker, and am baffled when people say it's "easy".

> but rather for much more complicated things.

You're giving me too much credit. It took me days to even get Docker installed. It turned out that despite a mountain of documentation telling me to install "Docker Machine", that's actually been discontinued for years and I should have been installing "Docker Desktop" instead.

[1] https://docs.aws.amazon.com/AmazonECR/latest/userguide/getti...

[2] https://docs.aws.amazon.com/cli/latest/reference/ecr/upload-...