Not saying this wouldn’t be disruptive. But it’s not a project ending scenario.
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.
https://www.digitalocean.com/community/tutorials/importing-p...
>import "github.com/google/uuid"
This should be just "google/uuid".
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).
> 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).
"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.
Unless Github or Gitlab goes out of business. Github might not be much of an issue, but what is some shifty company buys Gitlab during the next financial crisis?
Github has Microsoft money, so I wouldn't be to concerned, but even yanking Gitlab could break an insane amount of modules in one go. Having modules distributed among many domains reduce the chances of a large scale issue, for the cost of many small problems.