> the proper way to address this situation would be to compile static binaries
Nix is the proper way to address this. We'll get there eventually anyways, might as well bite the bullet now.
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.
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.
Yes, exactly what Nix does.
But some kind of repeatable environment is needed, traditional package management is just pure insanity where everything only works on one specific version.
Snap/Flatpak are broken by design, future tech won't need crutches like these.
They don't have very good deduplication but that's a fixable issue.
[It's still not a completely fixed problem - Nix needs to finish their content-addressable scheme, and for that you need reproducible builds; this is a detail, though.]