If you don't have enough manpower who can control and collaborate on the development of the environment, the project will not succeed to be adopted.
Programming language-specific dependency tools succeeded due to their user friendliness, however abysmal they are in multi-language / OS dependent environments (and I despise them for that reason). Cargo.toml, go.mod, conan.txt, Dockerfile etc. all are can be understood by basically all members of a dev team. You cannot say the same for Nix for most devs in a team.
Our direct experience counteracts this point. We have docs on how to add nix dependencies, and a file where they’re defined. For anything already packaged in nix, everyone can figure out how to add a line in that file to add something to everyone’s dev environment. We have over 3 years only wound up having to write our own derivations for two or three things.
We still use language-specific tools for those dependencies, though, since that is what people are familiar with. I think this strikes a fine balance: nix describes the “operating system” that we all work in, and then Cargo, npm, etc lockfiles describe each language’s dependencies.
Programming language-specific dependency tools succeeded due to their user friendliness, however abysmal they are in multi-language / OS dependent environments (and I despise them for that reason). Cargo.toml, go.mod, conan.txt, Dockerfile etc. all are can be understood by basically all members of a dev team. You cannot say the same for Nix for most devs in a team.