> In my opinion, every commerical software development team using Go should be using custom domains for namespacing their internal libraries and packages.
I’d remove “go” from the above, i.e. I think same applies to other stacks.
Even using GitHub domain links in code comments gets problematic long term. Ie when a migration happens and those links start pointing nowhere.
I mean yeah, but other languages don't make it quite so easy to make this mistake. Once your Go project gets to a size where it makes sense for different files to live in different folders (which, given Go's folder-based module system, often happens at just a couple hundred lines of code), the most straightforward way which the tooling nudges you towards means putting GitHub URLs (or URLs to whatever git host website you happen to use) in your source code.
yourname.internal/mymodule is even better. But don't expect to Go toolchain (especially "go get" or "go mod download") to work.
thih9 · · focus · HN ↗
I’d remove “go” from the above, i.e. I think same applies to other stacks.
Even using GitHub domain links in code comments gets problematic long term. Ie when a migration happens and those links start pointing nowhere.
mort96 · · focus · HN ↗
someonebaggy · · focus · HN ↗
dolmen · · focus · HN ↗
<a href="https://datatracker.ietf.org/doc/draft-davies-internal-tld/" rel="nofollow">https://datatracker.ietf.org/doc/draft-davies-internal-tld/