Don't Couple Your Go Code to GitHub

Go has a feature that is both a blessing and a curse: you namespace your code with the location where it can be fetched. If your code lives at github.com/thetrueares/boneclone, you import it as "github.com/thetrueares/boneclone" and Go fetches it via git. No central package registry needed. Simple, elegant, and it ties your code to a hosting provider.

Iain Cambridge wrote a post on Hacker News this week arguing that this coupling is a problem more Go developers should think about. If you move your repository from GitHub to GitLab, every import statement in every project that depends on your code has to change. The cost of switching hosting providers becomes so high that teams just stay put. He describes a company that ended up paying for GitHub, GitLab, and Azure DevOps simultaneously because migrating code between them was too painful.

The solution is custom domains. Instead of github.com/yourorg/yourlib, you use go.yourorg.com/yourlib. The domain serves a small HTML page with meta tags pointing Go's toolchain to the actual git repository. When someone runs go get, Go fetches the meta tag and clones from wherever it points. If you switch from GitHub to GitLab, you update the meta tag. The import path never changes. Nobody downstream has to touch their code.

Uber does this (go.uber.org). MongoDB does this (go.mongodb.org). It is not a new idea, but most Go projects still use raw github.com paths. Cambridge includes nginx config and HTML templates in his post so you can set it up in minutes.

The Hacker News discussion hit 222 points and over 100 comments, with the usual debates: some argue that GitHub is so dominant that vendor lock-in is theoretical, others point out that custom domains add a moving part (your DNS, your server) that can break. Both points are fair. But the cost of a custom domain is a few DNS records and a static page. The cost of being unable to leave a hosting provider is permanent.

For any commercial team using Go for internal libraries, this should be the default. The effort is minimal and the optionality is worth it.

Source: Iain Cambridge's Blog [1]
Hacker News discussion (222 points, 102 comments) [2]