Moreover, there's nothing stopping a Nix package author from writing a post-install script that causes state changes to be made out of bounds. The package manager isn't going to notice, and it's not going to clean it up at deinstallation time.
Every package in the store has exact dependencies - they reference the hashes of other packages only. When a package is built with Nix, only the directories for these packages are exposed to the chrooted environment in which the build occurs - so it is simply not possible for some randomly added junk in the filesystem to make it's way into a nix-defined package.
Contrast this to building software on another machine, where I might depend on "glibc" version "1.0". The combination these two values hardly represents a unique identity, as I could make any random package that fits those requirements. It's much more difficult for me to create a package which results in an hash collision though.
One thing that makes the other systems so unreliable is the presence of multiple repositories. If you were going to deploy packages from a single repository, then you can do careful planning in such a way that packages do not have any collisions. Assuming no user mutates the directories under control of the package manager, such system will also be effectively reproducible. Current mainstream distros work surprisingly well because they basically use this model, where a default repository provides most users needs. These distros quickly break down when you start adding third-party repositories which bundle alternative compilations of the same software that sits in the "official" one.
Basing packages from hashes (identity), rather than names and numbers, and making sure all of the files for each package is held in an isolated directory ensures that collisions won't happen, even if two different repositories provide the same software name and number, they are represented by different hashes, and will be treated as distinct pieces of software.
I'll continue to follow and learn more about Nix, but anxiously awaiting my epiphany.
[1] https://github.com/NixOS/nixpkgs/blob/1a504e3fb72fab10799cf0...
The thing is, "better" does imply "different." The syntax is weird and difficult, but it's the linchpin of the whole system. It's much, much better than your typical packaging system and worth the effort to learn it.
I take it configuration of the packages needs to go in nix as well? So what do you do when there is, for example, a change of upstream smtp?
Nix gives you tools for dealing with the concept of an immutable system - there's very few other working tools that do the same. Perhaps it can't possibly get all of it right - database setup and schemas, for example - but that's alright, you can use other tools to deal with them! (There's certainly a glut of schema management tools that would fit right into a Nix system.)
However, NixOS doesn't handle multi-system upgrades very well on its own - for example, you need to have some external way of dealing with "we need to upgrade the schema before restarting the application servers one at a time". I think that's a whole project on its own, and something that almost everything seems to do on an ad-hoc basis (Salt excluded).
