5 ms·

Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a f

Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a first party hacky workaround

anacrolix 3y ago
I agree. I've been using Go as my primary language since 2011. Its package management has always been fairly simple, but deficient. Go modules have made things more accessible, but it lacks serious features and actually has quite a few bugs and edge cases. Every time I use cargo I'm blown away, it's incredible. People often gloss over Go and lump it in with Rust which is giving it far too much credit.
- cogman10 3y ago
  I'm not saying it's great, but saying it was thought about even though one of go's design philosophies was to be as minimal as possible. That is, it's something that was thought of as part of the language development. The same can't be said of slightly older languages like C#, Java, or python. Perl, for all its foibles, was probably the first language with a more modern package management system (CPAN).
  - lyu07282 3y ago
    I think its more like pretending that things are simple (or that a simple solution is enough), when in truth some things just aren't simple and pretending otherwise is unwise. Like how they ended up adding a package manager later on, which of course was never part of the initial design because they thought nobody needs to version their dependencies. Or how they ended up adding generics later on, because they thought nobody will ever need to do "abstract things". The problem is if you don't consider these things in your initial design, the solution you end up with later tend to be worse.
tptacek 3y ago
Getting packages working in Go is approximately as low-friction as it is with any other language: "go get <whatever>". Packages are qualified by their Git repository URL, which addresses an important supply chain security issue (but creates other issues). Go has supported a thriving ecosystem of third party packages since approximately the moment it went mainstream. So, ultimately, all people are saying when they knock Go's package management is that they don't like how it works. That's fine, I don't like how all sorts of things work. But "nothing" is false, and "hacky" is so subjective as to be practically worthless. Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language, and, to me at least, it follows obviously that they solved package management to some level of the community's satisfaction, because languages without package management aren't successful. If we wanted to hash out the pros and cons of different package management strategies, that's all the thread will be: just hundreds of back-and-forth messages about package management. It's a big topic.
- 0cf8612b2e1e 3y ago
  >… Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language… When I wrote Go, the official language policy is that you do not need versioning and should not make breaking changes. Throw everything into a vendor/ if you must. For me, that kind of stance on package management definitely warrants attention.
  - tptacek 3y ago
    People have all sorts of thresholds past which attributes of package management warrant attention. Some of them are even reasonable. But it's not legitimate to claim that a language doesn't have any effective package management, at least when that language is (a) popular and (b) idiomatically dependent on 3rd party packages, simply because those thresholds get crossed. Go self-evidently has effective package management, and has for over a decade. There are lots of things I don't like about NPM. But imagine claiming that Node doesn't have real package management. You can't even write a for-loop in Node without a package. Go isn't quite that far gone, but it's pretty hard to write idiomatic Go of any significance with zero packages.
jonhohle 3y ago
Is it even fair to call them packages? It’s a slightly more convenient method of repo sub modules, but there isn’t any object reuse or sharing outside of a workspace.

Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a first party hacky workaround

anacrolix 3y ago

I agree. I've been using Go as my primary language since 2011. Its package management has always been fairly simple, but deficient. Go modules have made things more accessible, but it lacks serious features and actually has quite a few bugs and edge cases. Every time I use cargo I'm blown away, it's incredible. People often gloss over Go and lump it in with Rust which is giving it far too much credit.

cogman10 3y ago
I'm not saying it's great, but saying it was thought about even though one of go's design philosophies was to be as minimal as possible. That is, it's something that was thought of as part of the language development. The same can't be said of slightly older languages like C#, Java, or python. Perl, for all its foibles, was probably the first language with a more modern package management system (CPAN).
- lyu07282 3y ago
  I think its more like pretending that things are simple (or that a simple solution is enough), when in truth some things just aren't simple and pretending otherwise is unwise. Like how they ended up adding a package manager later on, which of course was never part of the initial design because they thought nobody needs to version their dependencies. Or how they ended up adding generics later on, because they thought nobody will ever need to do "abstract things". The problem is if you don't consider these things in your initial design, the solution you end up with later tend to be worse.

tptacek 3y ago

Getting packages working in Go is approximately as low-friction as it is with any other language: "go get <whatever>". Packages are qualified by their Git repository URL, which addresses an important supply chain security issue (but creates other issues). Go has supported a thriving ecosystem of third party packages since approximately the moment it went mainstream. So, ultimately, all people are saying when they knock Go's package management is that they don't like how it works. That's fine, I don't like how all sorts of things work. But "nothing" is false, and "hacky" is so subjective as to be practically worthless. Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language, and, to me at least, it follows obviously that they solved package management to some level of the community's satisfaction, because languages without package management aren't successful. If we wanted to hash out the pros and cons of different package management strategies, that's all the thread will be: just hundreds of back-and-forth messages about package management. It's a big topic.

0cf8612b2e1e 3y ago
>… Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language… When I wrote Go, the official language policy is that you do not need versioning and should not make breaking changes. Throw everything into a vendor/ if you must. For me, that kind of stance on package management definitely warrants attention.
- tptacek 3y ago
  People have all sorts of thresholds past which attributes of package management warrant attention. Some of them are even reasonable. But it's not legitimate to claim that a language doesn't have any effective package management, at least when that language is (a) popular and (b) idiomatically dependent on 3rd party packages, simply because those thresholds get crossed. Go self-evidently has effective package management, and has for over a decade. There are lots of things I don't like about NPM. But imagine claiming that Node doesn't have real package management. You can't even write a for-loop in Node without a package. Go isn't quite that far gone, but it's pretty hard to write idiomatic Go of any significance with zero packages.

jonhohle 3y ago

Is it even fair to call them packages? It’s a slightly more convenient method of repo sub modules, but there isn’t any object reuse or sharing outside of a workspace.