I've never heard of this being a bad pattern, could you elaborate a bit on that and how we are supposed to do it? If you have some dependencies on gitlab.com and some on github.com, how will your go.mod file look like if you are not supposed to use the full path?

Does that work? Pretty sure outside of the standard library you need the URL.

Only URLs are unique identifiers by construction so I think you're right. Wouldn't work.

My point was that’s not actually the problem in the grand scheme of things. Thats only an issue if the module is abandoned because then you cannot find the new host for it. And if the module is abandoned then you’ve got much bigger issues already regardless of the language and import semantics.

Plus if you really don’t want a full domain in your projects import paths then you can vendor in those modules, albeit at a cost of higher maintenance for yourself.

The biggest problem with having the domain name included in the import path is just purely visual noise. It’s pretty damn ugly. But that problem is purely aesthetic.

I will grant you that when package versions were encoded in the import path, that was extremely problematic (to say the least). But that’s gone away now we have proper module versioning (and I say that even as someone who doesn’t particularly like the solution that Go finished up with).

From your link

> Third-party packages are always known by their fully-qualified names, which include the site that hosts the code (e.g. github.com), the user or organization that develops it (e.g. google), and the base name (e.g. uuid).

Or maybe not.

"google/uuid" tells you nothing about the owner. It might be Google, or it might be me, who squatted the name early on.

"github.com/google/uuid" would be much difficult to squat. Also, it tells you that this comes from the Google user in GitHub, which is something much easier to verify.

"code.google.com/go/UUID" would be even more of a guarantee. But I guess they decided relying on GitHub to host their Go packages was good enough.