> that's not true, at least not in a larger context of available languages. There are C, C++, and a few other emerging language environments such as Mercury and ATS that can benefit from the same Nix toolchain right now, and their maintainers don't have to re-invent the wheel of packaging and distribution, as Nix solves that for them in a generic way.

Fair point, though Haskell seem to be the only language where Nix is the accepted solution to packaging and distribution.

> For that you need to define criteria that allow you to identify the "worst" example. It is going to be the worst if you expect a monolith all-included distribution that has its own implementation of the same generic dev tooling approach (reproducibility, tracking of dependency sources, versioning etc), such as Rust Cargo or Go Modules. But these criteria won't match with the world where I see every software component to be a generic build instruction that Nix manages to provide regardless of the underlying language compiler.

That's a reasonable point of view to have if you already know Nix. Most people don't, so they see Nix as Haskell-specific, except it's not and you now have to learn a general tool which usually takes way more time than learning Cargo or Go modules.

The point is that embracing Nix makes the learning curve of Haskell way steeper currently, especially when you also have GHC, Stack and Cabal. Maybe it will pay off in a few years when everyone uses Nix, but that's not the case today.