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.
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.
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.
But you can even have a rough estimate according to your own measure. There are roughly between 50K and 100K developers working at FAANG (maybe replace Netflix with Microsoft). How many of them would you guess are using Rust?
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.).
Rust wants not that I wants. It seems people replacing NodeJS with it.
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.
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.
> 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.
I'm not thinking in terms of language features but abstractions. The best way to see this is to think how many different implementations to a code unit I can do without making the consumer aware? That number is significantly lower for low-level languages compared to high-level languages because things that can be hidden in high-level languages, like layout, storage and lifetime, must not be in low-level ones, hence "low abstraction." Changing something in one place is more likely to require changes elsewhere. Therefore, low-level programs are more rigid, more jigsaw-like, and their evolution more difficult.
It is true that a compiler that tells you if you missed a change helps a lot, but it doesn't change the nature of the low-level language, even though it improves its ergonomics (although it's not so simple, as sometimes even correct programs are rejected) -- you still need to do all the extra work, but it doesn't take quite as long.
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.