It's not about obtaining binaries that work anywhere, it's about being able to ask for a predictable environment to run in. You don't have to care about the target environment if you can control the derivation that is built to run your program.
I think we also need to separate "Nix" from "The General Approach that is implemented by Nix (and Guix etc.)". I think the "The Nix Approach" (as I'm now going to call it) is fantastic and really is the solution to a lot of problems that we have. I think that the actual implementation of Nix isn't great and painful to use in real life.
> You don't have to care about the target environment if you can control the derivation that is built to run your program.
This is not always possible, since people may have workflows based on different containers or OSes. I (and the author of the article) want to have tools that work across different environments.
> The General Approach that is implemented by Nix (and Guix etc.)
"Reproducible builds" or "hermetic environments" are commonly used adjectives for this, although they are not limited to these two tools either; Bazel from Google does it too, for example.
I think Snap/Flatpak could probably be extended to cover most of the nix use cases.
But some kind of repeatable environment is needed, traditional package management is just pure insanity where everything only works on one specific version.
I don't really see anything broken about them besides the lack of a FOSS snap backend, and the fact that the security isolation still breaks apps sometimes.
They don't have very good deduplication but that's a fixable issue.
I think we also need to separate "Nix" from "The General Approach that is implemented by Nix (and Guix etc.)". I think the "The Nix Approach" (as I'm now going to call it) is fantastic and really is the solution to a lot of problems that we have. I think that the actual implementation of Nix isn't great and painful to use in real life.