4 ms·

> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Most new languages that I know of have a package

> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Most new languages that I know of have a package manager/inbuilt dependency resolution mechanism and a fairly robust module system to try and support 3rd party dependencies. Rust, Go, Dart, D. You can expect every language post 2010ish to have this.

throwboatyface 3y ago
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.
__MatrixMan__ 3y ago
Would you say that that's a good thing? I'm so tired of trying to figure out which package manager is responsible for which thing and keep track of their various idiosyncrasies. I think nix might be the way--just have one package manager to rule them all--but I'm not aware of any language ecosystems that are leaning into this.
- cogman10 3y ago
  > Would you say that that's a good thing? Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee. > but I'm not aware of any language ecosystems that are leaning into this. Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages. For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.
  - nequo 3y ago
    > the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. To be fair, Haskell doesn't have 20. It has two.
    - cogman10 3y ago
      Just a sec, let me go create 18 more ;) But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.
  - __MatrixMan__ 3y ago
    Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world. It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different. They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them. Learning languanges would be so much fun if I didn't have to learn a new package manager each time.

throwboatyface 3y ago

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.

__MatrixMan__ 3y ago

Would you say that that's a good thing? I'm so tired of trying to figure out which package manager is responsible for which thing and keep track of their various idiosyncrasies. I think nix might be the way--just have one package manager to rule them all--but I'm not aware of any language ecosystems that are leaning into this.

cogman10 3y ago
> Would you say that that's a good thing? Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee. > but I'm not aware of any language ecosystems that are leaning into this. Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages. For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.
- nequo 3y ago
  > the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. To be fair, Haskell doesn't have 20. It has two.
  - cogman10 3y ago
    Just a sec, let me go create 18 more ;) But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.
- __MatrixMan__ 3y ago
  Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world. It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different. They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them. Learning languanges would be so much fun if I didn't have to learn a new package manager each time.