Exactly! But trusting a remote repo to contain an essential part required to build the project is just extremely short-sighted, no matter what language is being used.

I think it is okay, as long as you have a backup plan. Can be advantageous to keep the code required to build the project small and have people pull dependencies as required.

IIRC, Go does not support importing anything but HEAD (yet, at least).

Go supports some versioning. It will checkout from:

1. A tag named for the version of go used, or 2. A branch named for the version of go used, or 3. The master branch

But no, you can't spec a version to import explicitly.

Transitive dependencies (pkgA imports pkgB@v1 but my code need pkgB@v2 which is incompatible with v1) are the thing of nightmares in large systems development.

This is a decided on feature by the golang team, not an oversite or something beyond their technical capabilities.

Yeah, but you can use any number of systems to keep track of it if needed. I'm using git submodules in my current project, which keeps track of what commit you are using.

Submodules are flawed in a lot of ways, but as a simple way to to keep a pointer to the appropriate version of an external project they are great. It's a little extra work to set them up, but it's fairly marginal. Check them out with go get, add the repo after the fact with git submodule, and after that just use git submodule to always grab the correct versions.

Github is not a substitute for a packaging system.