It's easier to use than all of the above, since it just works nearly all of the time - the beauty of having identities for packages and complete dependency chains means that building software on one machine should be reproducible on another machine of the same architecture. Failure to build is not a human-error or missing dependency - it's a bug, and the package distributor is to blame, not the person trying to build.
It's difficult to break because packages are immutable, and the /nix/store where they are held is read-only - it can only be modified by a user with root privileges (which should be never), or the nix daemon (which runs as root).
The caveat is that packages have identities - you can't simply swap out a dependency for an equivalent version which has a different identity, without also updating all of the dependents of that package. "Swapping out" is the wrong term, since all versions can live alongside each other - it's more that, applications at the bottom of the chain will not automatically receive the updates of dependencies (for bug-fixes, etc) - you must also update all dependents to make use of such bug-fixes. For a bug-fix in the compiler for instance, that effectively means updating the entire distribution.
This could open up significant challenges in the area of live-patching on running systems, as the current research and tooling for this is built on the assumption that you can overwrite packages. On the other hand, I actually think Nix provides a better model for live-updating, because immutability is much more suited to making the kind of transactions we really need to perform them.
Arguably, shared libraries could be obsoleted and everything could be statically linked too, which could provide performance gains at the cost of memory/storage.
It's difficult to break because packages are immutable, and the /nix/store where they are held is read-only - it can only be modified by a user with root privileges (which should be never), or the nix daemon (which runs as root).
The caveat is that packages have identities - you can't simply swap out a dependency for an equivalent version which has a different identity, without also updating all of the dependents of that package. "Swapping out" is the wrong term, since all versions can live alongside each other - it's more that, applications at the bottom of the chain will not automatically receive the updates of dependencies (for bug-fixes, etc) - you must also update all dependents to make use of such bug-fixes. For a bug-fix in the compiler for instance, that effectively means updating the entire distribution.
This could open up significant challenges in the area of live-patching on running systems, as the current research and tooling for this is built on the assumption that you can overwrite packages. On the other hand, I actually think Nix provides a better model for live-updating, because immutability is much more suited to making the kind of transactions we really need to perform them.
Arguably, shared libraries could be obsoleted and everything could be statically linked too, which could provide performance gains at the cost of memory/storage.