There are many who would dispute your assertion very vigorously. I mean...the core issue was being able to have semantic import versioning, which is a feature most languages used in very large projects do not have. (And the most widely used language to try and solve the underlying issue is node, which is not well known for its suitability for large, complex projects, so...) And Cox tried and failed to explain why he thought semantic import versioning was important to a committee that included many people who had worked on large projects written in Go and other languages, so...must be a bit of a subtle issue. :)
But sure. Fine. Let's just accept your entire claim as fact for the sake of argument, because even so, the real concerns here have nothing do with whether or not dep was fit for purpose, it has to do with the Go team's unwillingness to work with the community over what it would mean for a modules tool to be fit for purpose.
If you piece together the different accounts, we can say with some confidence what happened, and it's pretty clear that the core issue is the dep team wanted to work with the Go team on a solution that met the needs of everyone, and the Go team did not, so they didn't.
Which is fine, of course. Cox had every right to refuse to talk to the dep team, throw their work away, and re-implement it from scratch. I'm sure he enjoyed developing vgo, and perhaps it even saved him time compared to having to explain his ideas to the plebians on the dep committee...but even if so, that's not how you have a successful community driven project.
> Rust does the right thing there, this is a fact.
Ironic then, that dep was a straight up effort to copy Cargo, and most critic's of the Go teams management of the language have looked to Rust as an inspiration.
