Sure, there are a number of similar tools for Go. Over the next couple years, I suspect the community will settle on a "standard." I think it's the lack of a standard that the OP is bemoaning. Go just isn't old enough for that yet.

They are not standard. setuptools, cabal, Maven, et al. are. I have two Go libraries, and I do (and cannot) specify its version dependencies in a standardized manner.

Maven isn't standardized. There are still a lot of projects that use Ant + Grail or Gradle. There's also OSGI, which is sort of yet another way to manage dependencies in Java.

Maven doesn't prevent versioning issues from cropping up, either. One common example is where dependency A pulls in library C 1.0, but dependency B pulls in library C 2.0. They often conflict, and then your software fails at runtime (fun fun!) There are a bunch of hadoop bugs where exactly this happened, although I'm too lazy to look up the JIRAs right now.

I feel like if you want a stable version of something, you should use yum, apt-get, or your package manager of choice. I don't think the programming language should try to do the package manager's job. It never seems to end well.

So far, I haven't seen actual harm caused by a lack of library version numbers, and there seems to have been a lot of good done (people using and testing latest versions, green master policy, etc).