The Curse of NixOS
I&#x27;ve been using Nix and NixOS for a while and I&#x27;ve seen <i>four</i> core advantages:<p>1. Nix store: what the article covers: multiple versions of the same package, &quot;virtualenv for everything&quot;... etc<p>2. Reproducibility: because package <i>definitions</i> are self-contained, I can pin and reliably reproduce <i>everything</i> for my packages. And I do mean everything.<p>3. Flexibility: Nix works for system packages on NixOS as well as user packages on <i>any</i> Linux <i>or</i> macOS. I&#x27;ve been sharing like 70% of my system config between Linux and macOS, and I don&#x27;t know of any other tool that can do that.<p>4. Programmability: package definitions and config are <i>extensible</i> and <i>composable</i>. Yes, learning an <i>ad hoc</i> language to do this is a pain, but once I learned it I got a higher-level and better-abstracted way to define and combine packages than any other tool I&#x27;ve used. It&#x27;s like going from C to OCaml. At this point I&#x27;ve started hating Dockerfiles because they <i>can&#x27;t</i> easily be composed and <i>don&#x27;t</i> provide any real facilities for abstraction.<p>Ultimately, Nix took system management from feeling like an operational activity—maintaining and changing a bunch of mutable state to run the system—to declarative programming. Learning curve aside, making system management a reproducible programming activity with no system state to worry about has been a massive improvement.