You'll already have to recompile because go is statically linked. The current state of the art is just vendoring dependencies (see godeps) which means they nev

You'll already have to recompile because go is statically linked. The current state of the art is just vendoring dependencies (see godeps) which means they never get updated ever. Security updates don't happen now, and version pinning by vendoring is a hack, so it would be better to at least have version pinning built in so I can delete a few million lines of (vendored) code from my repository and instead just use a better import path. I assure you that that will be easier than dealing with the hell of vendoring tools and hacks go has now. And yes, the semver way to do it is great and is actually done well in some ecosystems. npm does a really good job of encouraging users to use semver and as a result you can just say "I want the latest 1.1.x release" or "1.x.x". The hardest problem there is to get people to version things. Your next point, that you don't want to recompile all go programs, is where I'll again point out go is statically linked. The authors of the language designed it so that no, you can't just update a go library in one place and build once. You have to build everything that depends on it again. You have to hope there were no breaking changes or you have to backport patches. Go does not handle this and is designed so as to be actively hostile to security. And yeah, the idea that semantic changes are backwards incompatible is a developer call, but you need a programmatic way to express it.... hence semver. In conclusion, having that sort of import-path thing would be awesome not because it solves any of the things you complain about (it doesn't) but because it's a step in the right direction. Any change is good change when your package management is "eh, fuck it" like Go's is now. If you look at all other good package managers (e.g. npm, rubygems, crate, etc) you can specify a repository and specific commit because there are plenty of valid cases for that, even when you have other options. No one is saying Go shouldn't have those other options in the future too here, just that having this option is a step in the right direction.