4 ms·

Language ecosystem is more important than the language itself. Typing 5 lines of code because of fancy syntax is nice, but writing 20 doesn't take a significant

Language ecosystem is more important than the language itself. Typing 5 lines of code because of fancy syntax is nice, but writing 20 doesn't take a significant amount of time. What does take tons of time however is figuring build systems, packaging, distribution, debugging, editor support, documentation, community, libraries, etc... I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose.

remexre 3y ago
> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Honestly, this is a lot of the draw of Go and Rust for a lot of people; other than debugging (which I can't speak to from experience, but as I understand it, both are on par with C++), the points you hit on above are all things Go and Rust have really solid answers to compared to their contemporaries.
cogman10 3y ago
> 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.
jonahx 3y ago
> What does take tons of time however is figuring build systems, packaging, distribution, debugging, editor support, documentation, community, libraries, etc... Yes. https://www.hillelwayne.com/post/learning-a-language/ https://www.hillelwayne.com/post/learning-a-language/
- winny314 3y ago
  Op here. I disagree. You can get up and started in most language stacks fairly quickly. Keep focus, learn to sort advice into helpful and unhelpful buckets, and start building with a goal in mind. For example - I hadn't touched fennel nor Love2d until about a month ago, and we made something happen. You can do this too.
  - jpe90 3y ago
    I recently learned Fennel and cranked out a Love2D game as well. Not only that, but I discovered it’s trivial to run the game on some spare nintendo consoles I have lying around, because Lua is insanely portable. In contrast, I spent a ton of time trying to build other lisps that are designed to be embeddable on those consoles and got nowhere. Fennel rocks. Such a pragmatic and well designed mini-language.
  - jonahx 3y ago
    You can get started quickly, yeah. You can also build some stuff. It might be useful, even. The article is about what it takes to really know a language. That's a bigger task. It takes months, if you work fast. That's how you write high-quality, maintainable software. You can do this too.
badsectoracula 3y ago
> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. In a way it is. After all if i make a new language, i can control what it can do and how it evolves but i can't control other people to force them use it.
tikhonj 3y ago
Typing 20 lines doesn't take much more time than typing 5 lines, but dealing with 5x more code thanks to an inexpressive language sure is an ongoing drag on productivity that just gets worse over time—while figuring out tooling/packaging/etc is, mostly, an up-front cost. Obviously better tooling is better, but my experience has been that ≈everyone overvalues up-front costs vs ongoing costs because they're more legible. Frankly, I wish new languages focused more on flexibility and expressiveness even if that made things harder up-front!
- dunefox 3y ago
  > Frankly, I wish new languages focused more on flexibility and expressiveness even if that made things harder up-front! Design languages for experts, not beginners. It might be more difficult to get started but if it's well designed it pays off.
paulddraper 3y ago
> I'm surprised no new languages focus on ecosystem. All of them? Go, Rust, Kotlin, TypeScript
kjs3 3y ago
Sounds like Cobol. I get asked (not that I'm an expert, but I occasionally live in the strange ether between the mainframe and the fad-driven front-end) 'how hard is it to learn Cobol?'. Not so hard. But knowing Cobol is about 20% of the job. Knowing all the mainframe ecosystem (z/OS, CICS, etc) is what takes serious time.

remexre 3y ago

> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Honestly, this is a lot of the draw of Go and Rust for a lot of people; other than debugging (which I can't speak to from experience, but as I understand it, both are on par with C++), the points you hit on above are all things Go and Rust have really solid answers to compared to their contemporaries.

cogman10 3y ago

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

jonahx 3y ago

> What does take tons of time however is figuring build systems, packaging, distribution, debugging, editor support, documentation, community, libraries, etc... Yes. https://www.hillelwayne.com/post/learning-a-language/ https://www.hillelwayne.com/post/learning-a-language/

winny314 3y ago
Op here. I disagree. You can get up and started in most language stacks fairly quickly. Keep focus, learn to sort advice into helpful and unhelpful buckets, and start building with a goal in mind. For example - I hadn't touched fennel nor Love2d until about a month ago, and we made something happen. You can do this too.
- jpe90 3y ago
  I recently learned Fennel and cranked out a Love2D game as well. Not only that, but I discovered it’s trivial to run the game on some spare nintendo consoles I have lying around, because Lua is insanely portable. In contrast, I spent a ton of time trying to build other lisps that are designed to be embeddable on those consoles and got nowhere. Fennel rocks. Such a pragmatic and well designed mini-language.
- jonahx 3y ago
  You can get started quickly, yeah. You can also build some stuff. It might be useful, even. The article is about what it takes to really know a language. That's a bigger task. It takes months, if you work fast. That's how you write high-quality, maintainable software. You can do this too.

badsectoracula 3y ago

> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. In a way it is. After all if i make a new language, i can control what it can do and how it evolves but i can't control other people to force them use it.

tikhonj 3y ago

Typing 20 lines doesn't take much more time than typing 5 lines, but dealing with 5x more code thanks to an inexpressive language sure is an ongoing drag on productivity that just gets worse over time—while figuring out tooling/packaging/etc is, mostly, an up-front cost. Obviously better tooling is better, but my experience has been that ≈everyone overvalues up-front costs vs ongoing costs because they're more legible. Frankly, I wish new languages focused more on flexibility and expressiveness even if that made things harder up-front!

dunefox 3y ago
> Frankly, I wish new languages focused more on flexibility and expressiveness even if that made things harder up-front! Design languages for experts, not beginners. It might be more difficult to get started but if it's well designed it pays off.

paulddraper 3y ago

> I'm surprised no new languages focus on ecosystem. All of them? Go, Rust, Kotlin, TypeScript

kjs3 3y ago

Sounds like Cobol. I get asked (not that I'm an expert, but I occasionally live in the strange ether between the mainframe and the fad-driven front-end) 'how hard is it to learn Cobol?'. Not so hard. But knowing Cobol is about 20% of the job. Knowing all the mainframe ecosystem (z/OS, CICS, etc) is what takes serious time.