I think people are seduced by some of the modern language features (like pattern matching, etc) by some of the third party libraries, by async [careful!], and primarily also by the WASM story that seems to be kind of going along with Rust. And by the novelty. And by promise of vaguely defined "performance."
But none of this is unique to Rust. And I'm not convinced on the WASM stuff at all for writing web front ends, though I'm enamoured of it as a generic backend managed VM, but that's another story.
And I think adopting Rust in many shops with a mix of developer seniority levels will be a productivity killer. I think most places doing this kind of thing would probably be better off with TypeScript, or Kotlin. Or if they want to go more functional and exotic, F#, Scala, OCaml, or Erlang/Elixir, etc.
But for places where we've been doing C++ for years and setting off footguns all over the place? Rust is great! Love it.
If Rust leads to more languages for more domains adopting Rust-style enums and pattern matching (algebraic data types / sum types -- this idea predates Rust by decades, so "modern" is an interesting term to use), I'd call that a big win for everyone. :)
It's pretty tricky to do that in an untyped language. But TypeScript could have this, or maybe even already does?
I mean, sure, why are we calling it "Rust-style"; it comes from ML and its descendants and Rust is obviously very influenced by them. When I say "modern" I really mean... finally learned from what "we" were "all" reading about on Lambda The Ultimate 20 years ago about languages designed 40 years ago that were not part of the mainstream until about 5-10 years ago :-)
I used "Rust-style enums" because if I just say "enum" then people think I mean something else. ;) And then I added the clarification to make sure nobody thinks I would claim that Rust invented Rust-style enums.
If I just say "algebraic data types" or "sum types" I fear many people won't know what I mean...
I think "discriminated union" is a useful bridge term here, even if it does confuse C programmers due to the conflated meanings of both enum and union in that language. It better represents the concept at an implementation level, and maps it to the C structure that enums more closely resemble in practice.
From a quick scroll, that seems to be just C-style `select` with `if` guards?
What I was referring to is things like `match x { Some(y) => ..., None => ... }`, where there is data that is available only in some variants of the type (like `y`). Without a type, even naming these variants becomes an interesting problem. (Not unsolvable, mind you. But not obvious either, and you lose some of the benefits that algebraic data types have in typed languages.)
