4 ms·

Maybe. But javascript is arguably in that phase of its life as well, and JS has had a oodles of wonderful new features added in the last decade. Features like t

Maybe. But javascript is arguably in that phase of its life as well, and JS has had a oodles of wonderful new features added in the last decade. Features like the spread operator, generator functions, async, arrow functions, leftpad, a new Date, and so on. The list of significant new features is endless. All that, despite JS being much older than rust, and much more widely used. Javascript also has several production implementations - which presumably all need to agree to implement any new features. Javascript had a period of stagnation around ES5. The difference seems to be that the ecmascript standards committee got their act together.

gary17the 2y ago
Javascript has a quite different use-case audience than Rust. As an example, try to convince a guy like Linus Torvalds to officially support a particular PL for Linux kernel development, when his absolute priority (quite rightly so) is predicable, performant and portable code generation on the same level as raw C, with ease-of-use of a PL not being even a distant second, if considered at all. JavaScript does not really have to live up to those kinds of challenges. The assumption that "[Rust] stagnation" is due to some kind of "Rust committee inefficiencies" might be incorrect.
- josephg 2y ago
  Author here. > Javascript has a quite different use-case audience than Rust. Eh. That sounds like a "just so" explanation to me. Linus Torvalds doesn't work on the rust compiler. I think I could make much more convincing arguments that javascript should move slower than rust - given there's so many large language runtime projects. (V8, Safari, Javascript, Node, Deno, Bun, etc etc). But evidently, that isn't the case. I'm open to the reason for rust's slow development being that the language developers want the language to move slowly. Thats fine. But, I personally don't want that. I've been waiting for generators to ship for 7 years. Or TAIT to appear - again, for years. I'd much rather rust to move faster. Of course I attribute all of this to the process & team which makes these decisions. What else is there? What else has any affect on the development of rust?
  - gary17the 2y ago
    No, Linus Torvalds doesn't work on the Rust compiler, but it is up to people like Linus to support or shoot down a particular PL for a particular use case. And here we arrive at the heart of our discussion: I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features. It is probably simply not possible to have a PL that does everything for everyone.
    - josephg 2y ago
      > I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features. Some of the "cutting-edge PL features" I want are things like function effects - which would allow you to (at compile time) mark that a function cannot panic. This is something the linux kernel has been asking for from rust for years. I think our interests are aligned.
      - biorach 2y ago
        > Some of the "cutting-edge PL features" I want are things like function effects That's probably the least convincing of your examples. My understanding is that effects systems can get complicated fast, and there's no consensus yet on what a good general purpose implementation should look like, never mind a specific implementation for Rust.
      - sandywaffles 2y ago
        > I want are things like function effects And it's not a cut and dry issue to add. Function effects would add a lot of cognitive load to the developer along with more implicit bounds which increases accidental API break changes. You talk about the compiler implicitly adding the bounds to functions, but what happens when I now add a line in my function that allocates when before it didn't? I just broke my API unless I was also defensively testing all implicit bounds. And if I was testing all implicit bounds, can the language no longer add new bounds? Reversing that and requiring the callee to defensively declare all bounds is a borderline non-starter because it'd such a huge burden to write any function or refactor anything.
tinco 2y ago
They got their act together because there was a language built on top of Javascript that fixed all its problems, and it was quickly gaining wide adoption. If they hadn't done anything, we'd probably still be transpiling CoffeeScript. History repeated itself, and now Typescript has even more popularity than CoffeeScript ever did, so if the ecma committee is still on their act, they're probably working on figuring out how to adopt types into Javascript as well. More relevant to this argument, is the question if a similar endeavor would work for Rust. Are the features you're describing so life changing that people would work in a transpiled language that had them? For CoffeeScript, from my perspective at least, it was just the arrow functions. All the sugar on top just sealed the deal.

gary17the 2y ago

Javascript has a quite different use-case audience than Rust. As an example, try to convince a guy like Linus Torvalds to officially support a particular PL for Linux kernel development, when his absolute priority (quite rightly so) is predicable, performant and portable code generation on the same level as raw C, with ease-of-use of a PL not being even a distant second, if considered at all. JavaScript does not really have to live up to those kinds of challenges. The assumption that "[Rust] stagnation" is due to some kind of "Rust committee inefficiencies" might be incorrect.

josephg 2y ago
Author here. > Javascript has a quite different use-case audience than Rust. Eh. That sounds like a "just so" explanation to me. Linus Torvalds doesn't work on the rust compiler. I think I could make much more convincing arguments that javascript should move slower than rust - given there's so many large language runtime projects. (V8, Safari, Javascript, Node, Deno, Bun, etc etc). But evidently, that isn't the case. I'm open to the reason for rust's slow development being that the language developers want the language to move slowly. Thats fine. But, I personally don't want that. I've been waiting for generators to ship for 7 years. Or TAIT to appear - again, for years. I'd much rather rust to move faster. Of course I attribute all of this to the process & team which makes these decisions. What else is there? What else has any affect on the development of rust?
- gary17the 2y ago
  No, Linus Torvalds doesn't work on the Rust compiler, but it is up to people like Linus to support or shoot down a particular PL for a particular use case. And here we arrive at the heart of our discussion: I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features. It is probably simply not possible to have a PL that does everything for everyone.
  - josephg 2y ago
    > I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features. Some of the "cutting-edge PL features" I want are things like function effects - which would allow you to (at compile time) mark that a function cannot panic. This is something the linux kernel has been asking for from rust for years. I think our interests are aligned.
    - biorach 2y ago
      > Some of the "cutting-edge PL features" I want are things like function effects That's probably the least convincing of your examples. My understanding is that effects systems can get complicated fast, and there's no consensus yet on what a good general purpose implementation should look like, never mind a specific implementation for Rust.
    - sandywaffles 2y ago
      > I want are things like function effects And it's not a cut and dry issue to add. Function effects would add a lot of cognitive load to the developer along with more implicit bounds which increases accidental API break changes. You talk about the compiler implicitly adding the bounds to functions, but what happens when I now add a line in my function that allocates when before it didn't? I just broke my API unless I was also defensively testing all implicit bounds. And if I was testing all implicit bounds, can the language no longer add new bounds? Reversing that and requiring the callee to defensively declare all bounds is a borderline non-starter because it'd such a huge burden to write any function or refactor anything.

tinco 2y ago

They got their act together because there was a language built on top of Javascript that fixed all its problems, and it was quickly gaining wide adoption. If they hadn't done anything, we'd probably still be transpiling CoffeeScript. History repeated itself, and now Typescript has even more popularity than CoffeeScript ever did, so if the ecma committee is still on their act, they're probably working on figuring out how to adopt types into Javascript as well. More relevant to this argument, is the question if a similar endeavor would work for Rust. Are the features you're describing so life changing that people would work in a transpiled language that had them? For CoffeeScript, from my perspective at least, it was just the arrow functions. All the sugar on top just sealed the deal.