Earlier quoted context omitted.
> You've never compiled GHC from source? How long does that take on your machine? I have, but the point is that I don't have to, because there are transparent distributed builds in Nix that I utilise when I want to compile something big, as you say "real-world", fast. I split software into many small self-contained packages and delegate the work of compiling it all to remote machines configured for faster compilation…
Haskell is the only language where you seem to need Nix. That alone make a big difference for people trying to get into Haskell. I'd say it's also the only language where you seem to need dev-infra tooling. I can see how using Nix helps, but saying that "it's already solved on other level of dev-infra tooling" is basically a way to confirm "This language has some of the worst tooling I've ever encountered in my life.…
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.
> is basically a way to confirm "This language has some of the worst tooling I've ever encountered in my life."
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.