I don't think your impression of the current state of dependency management in Go is accurate. Pretty much everybody uses this:
I picked 5 "important" Go projects without checking first, and here's the solutions they use:
Kubernetes: The deprecated tool Godep + a pile of Make and Bash (which is the Go-est thing I've ever heard in my life)
Docker (Moby): vndr
Hugo: dep
Etcd: A bit of a mish-mash of dep and vndr, but mostly dep.
Cobra: Doesn't vendor dependencies, isn't a reproducible build (which is somewhat okay, as Cobra is primarily a library, not a tool in and of itself, but it does also have a CLI that probably breaks a lot).
In short, things are not currently fine. Dep is an okay tool, but fails for some use cases, and the community has not really rallied around it. Lots of important projects are sticking with what they've got. Glide, gvt, vndr, and Godep all remain important.
We're deluding ourselves if we discard an outsider's view that Go's dependency management situation is a dumpster fire, because it is. However, to GP, it isn't quite as bad as you suggest, most projects using Go have found some way or another of getting reproducible builds, and don't just run everything from tip of everyone else's master.
I am cautiously optimistic that modules will finally solve this mess, but we'll see to what extent they win in the marketplace of dependency management solutions.
Godep, dep, glide, make files, you name it. it's a total dumpster fire.
I haven't written Go in a couple years, but I lol'd. This exactly what we used to do, except replace Godep with glide.
Having the ability to do so does not mean it should be the easiest and simplest way to get from A to B.
Both pip and cargo can pull from repositories, but it's not the default and it's basically not covered in any tutorial. It's easy to do, but a developer is unlikely to find the information before they're actively looking for it.
> If a developer doesn't understand proper git and package versioning they will have a hard time in any language producing quality software.
I don't understand why you're using Go if your teaching methodology is to throw live chainsaws at people and berate them for not understanding proper power tool safety, why are you not just cutting out the middleman and using C++?
clearly you just don't like Go, which is fine. Of all the languages I've picked up Go was far and away the simplest and most productive, which is why I continue to use it. When I wrote python we were constantly using pip to pull from repos, so moving to Go I liked their repository centric view. Just because python recommends pip, doesn't mean junior devs don't totally botch dependency management with it. Dep management and git are core skills developers need to learn well to produce good software. There is simply no substitute for a bit of elbow grease on the matter. I'm not berating anyone, software is hard and being good at it means taking the time to learn some core tools.
To characterize Go's ecosystem (but not Python's) as "throwing live chainsaws at people and berating them..." is pretty blatant dishonesty, doubly so once Go modules makes its official debut.