5 ms·

> Package management Are you seriously saying that github.com/somelib is a better package management? Of course nobody forces to use that, but it's what actual

> Package management Are you seriously saying that github.com/somelib is a better package management? Of course nobody forces to use that, but it's what actually been used in most go projects. Even NPM looks better in comparison. The best quality package management I've seen is Maven, followed by Cargo.

hellcow 5y ago
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.
angryfeller 5y ago
npm is just another layer on top of git. go uses git directly. how is that any worse?
- cris-ward 5y ago
  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.
  - saturn_vk 5y ago
    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
- ernst_klim 5y ago
  Does go have some intermediate cache repository between github and enduser?
  - uluyol 5y ago
    Yes, https://proxy.golang.org/ 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.
suddengunter 5y ago
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
mook 5y ago
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.
geodel 5y ago
> 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.
- Koffiepoeder 5y ago
  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.

hellcow 5y ago

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.

angryfeller 5y ago

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

cris-ward 5y ago
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.
- saturn_vk 5y ago
  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
ernst_klim 5y ago
Does go have some intermediate cache repository between github and enduser?
- uluyol 5y ago
  Yes, https://proxy.golang.org/ 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.

suddengunter 5y ago

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

mook 5y ago

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.

geodel 5y ago

> 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.

Koffiepoeder 5y ago
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.