> Toolchains on linux are not clear from dependency hell either - ever install an npm package.

That's where I stopped.

Toolchains on linux distributions with adults running packaging are just fine.

Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine.

I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.

The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.

And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it.

Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?

The real kicker is when old languages also fall for this trap. The latest I'm aware of is GHC, which decided to invent it's own build system and install script. I don't begrudge them from moving away from Make, but they could have used something already established.