Nix

Nix is the language underneath NixOS, and it is worth separating the two. NixOS is an operating system; Nix is a purely functional language for describing how software is built.

Why we still choose it

Because it solves a problem every other build tool works around: a build should be a function. Given the same inputs, a Nix expression produces a bit-identical output — on your laptop, in CI, on a server in Falkenstein, and again in three years. Dependencies are content-addressed rather than named, so two projects needing different versions of the same library is a non-event rather than an afternoon.

That property is what makes everything else we promise possible. Reproducible servers, staging that genuinely matches production, and a rollback that is a reboot all fall out of the build being deterministic in the first place.

Where it shows up in our work

Beyond the servers: development shells that give a new engineer the exact toolchain on their first morning, CI that builds the same closure the server will run, and flakes that pin every input by hash so “it worked last week” becomes a statement you can verify.

The honest limit

The language is genuinely strange the first time — lazily evaluated, purely functional, and with error messages that have historically been unkind. There is a real week or two before it clicks, and we do not pretend otherwise. What we can say is that the concepts are small in number; it is unfamiliar rather than complicated.