I sort of agree with the go authors that there is not idiomatic way to deal with dependency management at all. (see: https://golang.org/doc/faq#get_version) They all have their ups/downs and mostly it has to do with the language they are supporting.

Nodejs:

+ transparent code on download

- virtually impossible to mirror

- executes arbitrary 'script' blocks that install stuff on your system

- subpar transitive dependency management scheme

Java:

+ great transitive dependency management

+ private repos/mirrors are easy with well supported tools

- black box byte code with no licenses

- overly complicated software (ivy/maven)

Python (pip):

+ simple and easy

- virtual environment hell

There are things that i like and don't like with go get:

+ dirt simple and used from the command line

+ code comes into src/. This means that you can see the code and the licenses that you are pulling in. This makes it easy to inspect code in your project. I don't have a hidden code repo in my home directory or some crap.

+ I can clearly see the licenses that i'm pulling in. If you have a GPL in your project it's pretty trivial to audit this (unlike other tools were you have to track down the homepages of 20 random people).

- code is pulled from HEAD. Frankly this sucks. Hopefully people get their act together and release their software and got get will be able to pull a release. I can see the advantage of pulling from head if you're constantly iterating and monitoring for fixes. However, pulling from HEAD introduces the risk that there is a major untested defect in what you just pulled.

Overall as long as there is not a huge chain of dependencies in the code that you're pulling, and as long as you're relatively confident that HEAD isn't going to bust you release, it's a great system. Honestly I think that it makes the developer more wary about pulling in random half-baked code from the internet into their project. Maybe that's a healthy thing.