[pcx]

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

This! I've never heard anyone complain about this aspect of a package manager, EVER. vgo seems to be optimizing for a problem no one has.

[jcelerier]

> 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.

[pcx]

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

[lathiat]

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

[sametmax]

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

[trumpeta]

Scala / SBT has a particularly slow dependency resolution

[marcus_holmes]

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.

[pcx]

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

[amluto]

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

[baq]

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.

[pcwalton]

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

[asymmetric]

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

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