Don't couple your Go code to GitHub

Original Article ↗ Hacker News Discussion ↗

Go’s practice of using fully qualified URLs (often GitHub paths) as import identifiers is prompting concern over long‑term stability, vendor lock‑in, and painful migrations when repositories move. Commenters weigh alternatives such as custom domains, internal proxies, and vendoring dependencies, noting trade‑offs between resilience, security, convenience, and the operational burden on maintainers. Many argue that no namespace is failure‑proof, so the real challenge is designing tooling and workflows that make hosting changes and dependency preservation manageable over time.

Go import paths & GitHub coupling

  • Go’s “import == network path” design makes repository host part of the API surface.
  • Many see this as fragile: moving from GitHub to another forge (or even org rename) means touching import paths across many repos and historical tags, breaking old builds.
  • Others argue the problem is overstated: a rare migration plus search/replace or go.mod replace is acceptable overhead.

Custom domains / vanity URLs

  • Pro–vanity domain view: using your own domain decouples identity from any one forge; you can retarget DNS or simple web handlers (nginx, Hugo templates, vanity URL servers) to new hosts later, or even to an artifact registry.
  • Critics worry this just moves the SPOF: domains lapse, registrars can delete TLDs or raise prices, and abandoned domains can be taken over and abused.
  • For closed/internal code, domain control is seen as more reasonable; for long-lived OSS, some prefer a “stable big host” like GitHub.

Vendoring, proxies & reproducibility

  • Some advocate vendoring dependencies for every Go project: improves offline builds, resilience to upstream disappearance, and supply-chain control.
  • Others highlight drawbacks: bloated repos, slower git operations and CI, manual update work, recursive dependency complexity.
  • Go’s module proxy (proxy.golang.org) and internal mirrors are mentioned as middle ground: cache once, then build without hitting GitHub directly.

Migration pain & organizational scale

  • Multiple commenters describe real migrations (GitHub → other host, domain changes) as “horrible” at scale, especially with many repos and versions depending on each other.
  • Simple search/replace breaks when you need to preserve the ability to rebuild historical versions; you end up branching/tagging old commits just to rewrite import paths.
  • Monorepos with a single version of each dependency avoid some of this but introduce their own costs.

Security, integrity & package-system design

  • Concerns raised about:
    • Dead or hijacked domains/hosts serving malicious code.
    • Go’s reliance on locations instead of stable identifiers or content addressing.
  • Suggested improvements: content-addressable imports, hashes in go.mod (not just go.sum), signed modules, better redirect/alias mechanisms, or fallback to archives like Software Heritage.
  • Some see Go’s package story as an underdesigned system that accreted features (modules, proxies, replace) rather than a coherent registry-based design.