Until that time when they realize everyone else was right, and they add an over simplified, bad solution to their "great" language.
From my experience, Go's dependency management is far better than anything else I've worked with (across languages including Java, Scala, Javascript/Typescript, Python).
Your criticism is perhaps relevant in relation to language features (though I would disagree with your position) but has no basis in relation to tooling and the standard library, both of which are best in class.
Could you elucidate which of the 'mentioned issues' you think are present for Go (in relation to tooling) that do not apply to Rust/cargo? Is your critique based solely on the new `go tool` command or more widespread? And are you aware that the parent criticism is at least partially misguided given it is possible to store tooling in a separate .mod file or simply ignore this feature altogether?
You seem to only use languages with bad dependency management. Which sounds tongue in cheek, but it's true. These are the languages (along with Go) where people hate the dependency management solutions.
Having sad that, I don't really know anyone with significant Go experience who dislikes its dependency management - most critiques are now quite out of date/predate current solutions by several years.
Finally, I'm not really sure which language you are proposing has better dependency management than Go - whether in relation to security, avoiding the 'diamond' problem, simplicity, etc. Rustaceans like to critique Go (no idea if you are one but my experience is that criticism is often from this crown) but I'm not sure how, from my own Rust experience/knowledge, it is actually better. In fact, I think there are several grounds to think that it is worse (even if still very solid compared to some of the aforementioned languages).
Python isn't too bad now-a-days with poetry although the repo spec could use more constraints
Anything is better than npm, with one function per package.
Python, thankfully I only need batteries for OS scripting.
I would rather scratch my eyes out than use Go for the kind of code I write day-to-day, but Go looks amazing for the kinds of things where you can achieve high levels of boringness, which is what we should all be striving for.
I worked with C++/ruby/python/js/java and C#, go mod is superior to all them.
The one that is similar is Cargo ( rust ).
Of course, the problem with that was that it was pretty much impossible to version properly, causing breakages and such.
at least Go doesn't have virtualenvs
That said, I still strongly dislike that the Go ecosystem conflates a library's repo URL with it's in-language URI. Having `github.com` everywhere in your sourcecode just ignores other use-cases for dependency management, like running an artifactory in an enterprise setting. My point being: there's still room for improvement.
