[mwcampbell]

At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.

[nknighthb]

Google's internal developers operate in a vastly different world from the one most of us are used to, always building from the head of a single, massive Perforce repository.

When your world enforces the assumption that the latest version of a dependency is stable and compatible, 'go get' is a perfectly reasonable solution.

[wtbob]

> At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.

That's how 'go get' works.

[TylerE]

No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.

[wtbob]

> No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.

You get the dependency at a version control level, at a known-good version (because you pulled from the master branch) at the time you pulled, and after that it's up to you to update it.