> The speed of the solver is not a problem in any other package management system I've seen

really ? It has been a large problem in Debian for instance and has enabled a lot of research (https://scholar.google.fr/scholar?q=debian+solver). One of the reason for Fedora's yum -> dnf change was also a change of solver. It's a hard problem that affects a lot of people.

To clarify, I(and the OP) was specifically talking about programming language specific package managers.

puppet dependency managers have also been an issue it's certainly easy to solve poorly

You can't compare languages and os package manager. They are on a completely different scale.

Scala / SBT has a particularly slow dependency resolution

Go has always optimised for build speed. I guess they considered dependency resolution as part of the build process.

Which it technically is, I suppose, but when you're coding and iterating the code-build-run loop you generally don't need to add new dependencies each time. And that's when the build speed matters, of course.

And, most CIs cache build dependencies these days which is an easy work around.

I once waited for a long time for an older Haskell dependency solver to contemplate a situation before it gave up.

i've seen aptitude get really confused about what to install and computing a solution for a few minutes.

once.

10 years ago or so, i don't even remember.

I should clarify that I'm referring to language package managers. Their problem domains are significantly different than those of system package managers.

I'm curious, what makes the problem domains different?

I'm asking because I'm interested in "universal" package managers like nix.