It is quite complicated to understand or to set up, yes, but I agree that it is easy to use. We use it at work for our dev environments. Like two or three of us are able to actually add packages, adjust nix configs, etc. Everyone else just runs `direnv allow` and automatically gets everything they need to build and run out software.

> It is quite complicated to understand or to set up, yes, but I agree that it is easy to use.

The problem is that everything works--until it doesn't. And then nobody knows how to fix it.

You wind up needing a single person who serves as local "nix tech support" who then hates life because he's a high end devloper dealing with nix n00bs all day long.

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.