5 ms·

> Rust's designers need to choose between adoration and actual popularity. The latter will require some tough decisions. If it's going after the C++ market, it

> Rust's designers need to choose between adoration and actual popularity. The latter will require some tough decisions. If it's going after the C++ market, it should make itself extremely appealing, irresistibly so, to C++ programmers. And what decisions would that be? Your post seems self contradictory to me because it implies that Rust is both too "low abstraction" to be "extremely appealing" to C++ crowd, and too complex and "hard to analyze" to displace C in use-cases that require portability and/or are resource constrained.

pron 6y ago
I didn't say it's too low abstraction to appeal to C++ programmers; Rust and C++ (and Ada, and Zig) have the same level of abstraction. I'm saying that Rust should seriously fight for the market C++ was able to actually carve out, rather than the market C++ dreamed it could have when it first gained traction. Doubly so because Rust is starting at a disadvantage compared to what C++ had: C++ already exists, and many people already know that a language that looks high-level but isn't, doesn't have the same maintenance costs as actual high-level languages. If it doesn't focus, what will happen is that it won't capture enough C++ people, and instead, it will get many people who didn't learn C++'s lesson, who will use Rust for some years and then abandon it -- just as happened to C++ -- and then it will be left with not much; it will have too little of the C++ market and too little of the applications market. If there's anything we can learn from programming languages -- be they C, C++, Ruby, PHP, Haskell, or Java -- riding the hype-train led by PL enthusiasts and early-adopters is not a good recipe for long-term success (even if it is a good recipe for long-term hype). Like with fashion (and I think HN is more like GQ or Vogue than actual industry news; i.e. it is more aspirational and inspirational than descriptive or prescriptive), the languages people talk about and those they actually use for many years are usually not the same.
- nicoburns 6y ago
  > I'm saying that Rust should seriously fight for the market C++ was able to actually carve out, rather than the market C++ dreamed it could have when it first gained traction That's exactly what Rust is doing. It used to have a runtime, green threads and a GC, but it doesn't because that's not what C++ developers want. And recent development work has been focussed on const generics and const fn which are both keys things seen as missing by C++ developers.
- caskstrength 6y ago
  What exactly do you mean by making "tough decisions", "fight for the market" and "make itself extremely appealing"? I've just re-read both of you messages in this thread and didn't find any single specific technical suggestion.
  - pron 6y ago
    That's because I don't know how to do that, and it might not be purely technical. But what Rust is doing doesn't seem to be working. Six years since 1.0 and almost unheard-of levels of hype, market penetration isn't even at 0.1%. It's a language with Python-level coverage and Elixir-level adoption.
    - caskstrength 6y ago
      Well, yes, of course. Rust is not made by Apple, MS or Google who can just make it new "official" language on their platform and force adoption. Also, by its very nature (low-level-ish language without GC) it cannot have Python-level adoption in modern software development ecosystem. Why would you want Rust to target lowest-common-denominator developers and become new VB or php? All it needs is enough momentum to become self-sufficient, which seems to be actually happening now with Rust Foundation and news of its usage in some major companies that can set the trends for whole industry (Amazon, Google, etc.).
      - wealthyyy 6y ago
        > Why would you want Rust to target lowest-common-denominator developers and become new VB or php? Rust wants not that I wants. It seems people replacing NodeJS with it.
    - howinteresting 6y ago
      https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers https://insights.stackoverflow.com/survey/2020#technology-pr... says that 4.8% of professional developers are using Rust. From the perspective of someone who's been writing Rust professionally for the last few years, the hockey-stick curve started kicking in in late 2020 or so.
- howinteresting 6y ago
  Could you please make specific claims here? Arguments that don't provide any examples are generally worse than useless. I don't think Rust and C++ have the same level of abstraction, for example. Rust has ADTs and pattern matching, C++ only has product types and std::variant.
  - pron 6y ago
    Abstraction doesn't mean syntactic constructs. It means the ability to specify arbitrary aspects of behaviour and then provide interchangeable implementations of the behaviour. When abstractions can have more satisfying implementations, you have high abstraction; when they have less you have low abstraction (i.e. you can abstract only smaller groups of things). Replacing, say, a concrete type with a trait is about as much work in Rust as it is in Assembly. It's not a feature of Rust specifically, but of low-level programming. If you want control over object layout, placement, and lifetime, it means that you abstract over things with specific low-level details, so fewer things. This isn't a problem, but a tradeoff that low-level programming intentionally makes, that no syntax can erase.
    - howinteresting 6y ago
      Yes and no. Let's drill down into this because the details are important. There's a crucial distinction between input and output types in practice. For a given input type T, Rust makes it possible to abstract over `T`, `&T`, `Cow<'a, T>`, `Arc<T>` etc, by using a trait such as `impl AsRef<T>`. However, Rust doesn't currently have existential types, so its ability to abstract over output types is more limited. You can implement, for example, `fn foo(&self) -> impl AsRef<T> + '_`, but you can't name that type. So if you want to return an enum, you can't write ``` enum MyEnum { MyT(impl AsRef<T>), MyU(impl AsRef<U>), } ``` Instead, you have to concretize the type somehow, either by boxing things up into a trait object (often but not always possible) or by exposing the generic param: ``` enum MyEnum<RefT, RefU> where RefT: AsRef<T>, MyU: Ref<U> { MyT(RefT), MyU(RefU), } ``` This is a real problem, though one that will be solved through existential types. > Replacing, say, a concrete type with a trait is about as much work in Rust as it is in Assembly. I'm not sure what you mean here. I'm not aware of any assembly languages which have traits. Replacing a concrete type with a trait tends to be pretty easy in Rust because mistakes are caught at compile time.

pron 6y ago

I didn't say it's too low abstraction to appeal to C++ programmers; Rust and C++ (and Ada, and Zig) have the same level of abstraction. I'm saying that Rust should seriously fight for the market C++ was able to actually carve out, rather than the market C++ dreamed it could have when it first gained traction. Doubly so because Rust is starting at a disadvantage compared to what C++ had: C++ already exists, and many people already know that a language that looks high-level but isn't, doesn't have the same maintenance costs as actual high-level languages. If it doesn't focus, what will happen is that it won't capture enough C++ people, and instead, it will get many people who didn't learn C++'s lesson, who will use Rust for some years and then abandon it -- just as happened to C++ -- and then it will be left with not much; it will have too little of the C++ market and too little of the applications market. If there's anything we can learn from programming languages -- be they C, C++, Ruby, PHP, Haskell, or Java -- riding the hype-train led by PL enthusiasts and early-adopters is not a good recipe for long-term success (even if it is a good recipe for long-term hype). Like with fashion (and I think HN is more like GQ or Vogue than actual industry news; i.e. it is more aspirational and inspirational than descriptive or prescriptive), the languages people talk about and those they actually use for many years are usually not the same.

nicoburns 6y ago
> I'm saying that Rust should seriously fight for the market C++ was able to actually carve out, rather than the market C++ dreamed it could have when it first gained traction That's exactly what Rust is doing. It used to have a runtime, green threads and a GC, but it doesn't because that's not what C++ developers want. And recent development work has been focussed on const generics and const fn which are both keys things seen as missing by C++ developers.
caskstrength 6y ago
What exactly do you mean by making "tough decisions", "fight for the market" and "make itself extremely appealing"? I've just re-read both of you messages in this thread and didn't find any single specific technical suggestion.
- pron 6y ago
  That's because I don't know how to do that, and it might not be purely technical. But what Rust is doing doesn't seem to be working. Six years since 1.0 and almost unheard-of levels of hype, market penetration isn't even at 0.1%. It's a language with Python-level coverage and Elixir-level adoption.
  - caskstrength 6y ago
    Well, yes, of course. Rust is not made by Apple, MS or Google who can just make it new "official" language on their platform and force adoption. Also, by its very nature (low-level-ish language without GC) it cannot have Python-level adoption in modern software development ecosystem. Why would you want Rust to target lowest-common-denominator developers and become new VB or php? All it needs is enough momentum to become self-sufficient, which seems to be actually happening now with Rust Foundation and news of its usage in some major companies that can set the trends for whole industry (Amazon, Google, etc.).
    - wealthyyy 6y ago
      > Why would you want Rust to target lowest-common-denominator developers and become new VB or php? Rust wants not that I wants. It seems people replacing NodeJS with it.
  - howinteresting 6y ago
    https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers https://insights.stackoverflow.com/survey/2020#technology-pr... says that 4.8% of professional developers are using Rust. From the perspective of someone who's been writing Rust professionally for the last few years, the hockey-stick curve started kicking in in late 2020 or so.
howinteresting 6y ago
Could you please make specific claims here? Arguments that don't provide any examples are generally worse than useless. I don't think Rust and C++ have the same level of abstraction, for example. Rust has ADTs and pattern matching, C++ only has product types and std::variant.
- pron 6y ago
  Abstraction doesn't mean syntactic constructs. It means the ability to specify arbitrary aspects of behaviour and then provide interchangeable implementations of the behaviour. When abstractions can have more satisfying implementations, you have high abstraction; when they have less you have low abstraction (i.e. you can abstract only smaller groups of things). Replacing, say, a concrete type with a trait is about as much work in Rust as it is in Assembly. It's not a feature of Rust specifically, but of low-level programming. If you want control over object layout, placement, and lifetime, it means that you abstract over things with specific low-level details, so fewer things. This isn't a problem, but a tradeoff that low-level programming intentionally makes, that no syntax can erase.
  - howinteresting 6y ago
    Yes and no. Let's drill down into this because the details are important. There's a crucial distinction between input and output types in practice. For a given input type T, Rust makes it possible to abstract over `T`, `&T`, `Cow<'a, T>`, `Arc<T>` etc, by using a trait such as `impl AsRef<T>`. However, Rust doesn't currently have existential types, so its ability to abstract over output types is more limited. You can implement, for example, `fn foo(&self) -> impl AsRef<T> + '_`, but you can't name that type. So if you want to return an enum, you can't write ``` enum MyEnum { MyT(impl AsRef<T>), MyU(impl AsRef<U>), } ``` Instead, you have to concretize the type somehow, either by boxing things up into a trait object (often but not always possible) or by exposing the generic param: ``` enum MyEnum<RefT, RefU> where RefT: AsRef<T>, MyU: Ref<U> { MyT(RefT), MyU(RefU), } ``` This is a real problem, though one that will be solved through existential types. > Replacing, say, a concrete type with a trait is about as much work in Rust as it is in Assembly. I'm not sure what you mean here. I'm not aware of any assembly languages which have traits. Replacing a concrete type with a trait tends to be pretty easy in Rust because mistakes are caught at compile time.