Go has had built-in package management for a while now. It's extremely fast and generates reproducible builds effortlessly in its default behavior in a way I've not experienced before from any other tool.

As somebody currently working on something that has a mix of Node and Go, I definitely prefer github.com/somelib. In that case there's no worry about package name conflicts (everybody has equally terrible names), so you can always end up doing imports with reasonable names because only the last bit matters. With a single namespace, people can (and do) camp on the obvious names, and often they move on and replacement libraries have to have cute names.

This doesn't mean people _will_ name their things sensibly of course. I've seen golang projects with packages named after gardening, meteorology, and aviation… and each is totally confusing when you're new to it, especially when the naming theme is completely unrelated to what the project actually does.

Here maven would be acceptable (similar to go, there is a domain identifier embedded) whereas cargo (bare words) wouldn't be great.

I disagree

for private Go packages all I need is to point it to another git repo. for nuget/maven etc - I need an artifact registry, with it's own bells and whistles

> Are you seriously saying that github.com/somelib ..

Well, yeah, I mean if one can say Maven is best package management then I think I can get away by saying Earth is flat or stationary or some such interesting facts.

To be honest, maven is not the best, but I would take it any day above npm, pip and composer. It's definitely orders of magnitude better than many 'modern' package managers out there.

npm is just another layer on top of git. go uses git directly. how is that any worse?

From someone who briefly used 'bower', which was JS dependency management using git, relying on git is a lot worse.

Github repos can vanish, NPM will only let repos be deleted if they have no direct dependencies also on NPM. So you have some guarantees your dependencies wont vanish.

If the repo was used at least once, it will be cached by the default proxy. At that point, deleting it will have no effect on builds

Does go have some intermediate cache repository between github and enduser?

Yes, https://proxy.golang.org/

You can also configure go to use your own for internal projects or if you just want to avoid the global proxy.