>I can do (almost) all of these things with a traditional Linux distribution, git, and a few scripts written in my language of choice, and I can do it faster.
As someone who moved from a directory of numbered bash scripts and GNU Stow to Nix, I can't disagree more. The fundamental difference is one is imperative and the other is declarative (and reproducible), and that makes all the difference.
Exactly. I have used Linux since 1994, from Slackware to RedHat to Debian to Gentoo to Ubuntu to Arch.
NixOS and nix-darwin both using nixpkgs is the first time I have the exact same shell and programming/CLI environment on all five of my personal and work machines which run Linux and macOS.
I upgraded them all to the 23.05 versions from 22.05 by updating my flake.lock and doing a rebuild switch on all machines. No regressions.
Some cobbled together shell scripts and a Git home dir management system (yadm) is what I had before and it doesn’t come close. I also dreaded upgrades with the previous approach. And didn’t have nearly the same control pristine replicated environment across machines.
It’s even flexible enough that on Linux desktop machines I have X11 and bspwm DE environment, on servers no X11, and on macOS it configures my system preferences, Dock icons and installed App Store apps.
Reproducible is key here. I remember trying to manage servers with Ansible, Chef and Puppet in the past but was always disappointed that trying to spin up a new server, or move a service between two usually failed. This is because service S1 forget to declare dependency D, but it happened to work because S2 needed the same dependency and declared it. Or simply that in the past S1 declared D but the config was "cleaned up" and it wasn't realized that D was still needed. (Or it wasn't needed at the time but then needed again, but you didn't declare it).
These types of problems are very rare in NixOS (although I do occasionally see it with the module system, but at least this is config dependent, not system-state dependent). If I apply the same config I have a very high confidence that I will get the same system. I lost my desktop's drive the other day and I was back fully functional within an hour. Most of the time was spent logging into Firefox, Email and various websites rather than installing the system. Managing servers is similarly easy, I would have a hard time moving to something else.
Intrinsic state (like user data or application databases) is still hard, but at least that is the only real concern. Better than dealing with state and config.
In a 'divergent' system (e.g. managed by bash scripts), the resulting system state might diverge from what the bash scripts have, because of manually running commands on the system.
In a 'convergent' system, the system tries to reach a target state by comparing what's there with what it's got.
In a 'congruent' system, the system is forcibly built to equal the target state.
The term 'reproducible' in 'reproducible build' (https://reproducible-builds.org/) conveys "bit-for-bit identical output". -- The benefit of that is security; others can compile the same sources and check that they get the same binaries.
But more generally, 'reproduce' just means 'create the same thing again'.
Nix uses "reproducible" in a more general sense: you provide the same inputs, and you'll get a program which behaves the same way, regardless of whether you compiled from source or downloaded binaries from a cache.
IMO, I think "reproducible build" is enough to unambiguously refer to the former. But, if you can think of a nicer word for "you get the same behavior from the same inputs" than "reproducible", it would be worth suggesting.
As someone who moved from a directory of numbered bash scripts and GNU Stow to Nix, I can't disagree more. The fundamental difference is one is imperative and the other is declarative (and reproducible), and that makes all the difference.