> [go get] Only works for source code packages, not
> binary dependencies.
There's no such thing as a binary dependency in the Go ecosystem. (At least, not without stretching some definitions.) It's one of Go's greatest strengths, actually.
> There isn't a way to specific source code versions/tags
> in a portable way.
Well, the best practice is to vendor[0], and there are plenty of third-party tools like godep[1] that can manage it for you.
I don't know anything about Android or Dart development, so I can't speak for them. All I can say is that internal Google development has been happily using vendoring of third-party code for many years (and not just C/C++ code), so I'm confident in saying that vendoring Go code can work just fine for "boring closed source enterprise commercial library tooling".
My car doesn't have a blender, a mini-fridge, or a hot tub. Some cars do. I don't think my car is worse off because of their lack.
Along the same lines, my mother used to always buy cars that were manual transmission and without power windows or locks, because they were features which made the car cost more, broke often, and were expensive to fix. The minor conveniences they afforded were not worth the costs.
Only works for source code packages, not binary dependencies.
There isn't a way to specific source code versions/tags in a portable way. Also makes the import paths dependent on your repositories.