In this context, it would break a crap ton of Go modules, though. That’s the point, and git decentralization has nothing to do with it, unfortunately.

As some who writes a lot of Go and thus has actually had to deal with this problem already: the hard part is finding a new source for the module. Updating your project to point to the new module takes around two minutes tops. But finding that module is the hard part.

However this isn’t a uniquely Go problem. You have the same problem when switching to a new module in any language and the reasons you’d struggle is the same: because the existing module has been abandoned. If it hadn’t been abandoned then it’s very easy to find the new git repo and thus update your Go project.

> git decentralization has nothing to do with it, unfortunately.

It has everything to do with it. You have a local copy of the repo on your development machine and thus can throw a new mirror up if you need to. All you lose is any issue tracking and existing maintainers. But if you’re having to resort to this, those maintainers have likely already abandoned that module already.

The problem is people hardcoding github.com in their go files.

https://www.digitalocean.com/community/tutorials/importing-p...

>import "github.com/google/uuid"

This should be just "google/uuid".

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.