I think in conversation we don't separate the fundamental concepts that Nix implements from the particular implementation.
The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.
This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.
People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.
Indeed; GNU Guix is essentially the same thing, but with a different language and CLI (the two main source of complaints about Nix).
Similar to how Git has a notorious CLI; but that doesn't invalidate the idea of DVCS (with alternative implementations in Mercurial, Bazaar, Darcs, etc.)
I use nix as my package manager, but I would use Guix instead if it would support macs. Nix is a great idea but it has a huge amount of ground to cover in reducing onboarding friction.
The problems with NixOS are not the only ones you highlighted. The baggage it brings in the name of reproducibility is not justified in my eyes.
Because a) They're not the only ones working towards it, but they like to paint it that way and b) Their implementation is not the only correct way, and again they like to paint it that way.
The main people behind it may not feel like that, but the hype creates a very repulsive aura around the project for some of us. I just don't want to touch NixOS just because of the community and hype around it.
There are many ways to achieve this reproducibility, and the old school ways are not very behind when compared to NixOS. Some things are achieved differently, but it's perfectly achievable with Debian and RedHat packaging infrastructures.
The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.
This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.
People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.