[cmrdporcupine]

The measure of "mainstream" should not be "projects on github" but: code deployed (or actively deploying) in production. GitHub is full of personal interest and research and unfinished projects.

It will come. It's not there yet.

I still argue it's not the language best suited for what a lot of people are trying to use it for. It has a niche, one that I like, but I fail to understand why it's being deployed for web services type applications. IMHO it's not a good fit.

[IshKebab]

> I fail to understand why it's being deployed for web services type applications. IMHO it's not a good fit.

There are plenty of reasons why it's a good fit for web services. It's fast, has great tooling, a great library ecosystem, and perhaps most importantly the strong type system and borrow checker mean you write far fewer bugs than in most other languages (C++, Java, Typescript, Go etc; maybe not Haskell).

The only reason I wouldn't use it in web services is because the whole ecosystem seems to have decided that everything has to be async despite that adding a ton of complexity and almost nobody needing it.

[solar-ice]

Entirely agree with that - and I'm a professional Rust dev, working with video. It's like using C++ for web services. Why would you do that?

[cmrdporcupine]

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.

[ralfj]

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?

[cmrdporcupine]

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 :-)

AFAIK TypeScript doesn't have ML-style pattern matching, but its type system is fairly expressive and you can do something "like" it https://dev.to/gvergnaud/bringing-pattern-matching-to-typesc...

[ralfj]

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

[stormbrew]

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.

[int_19h]

> It's pretty tricky to do that in an untyped language.

If you mean dynamically typed, then Elixir has it:

https://elixir-lang.org/getting-started/case-cond-and-if.htm...

[ralfj]

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

[int_19h]

No, it matches on the structure of data as well as embedded values. E.g. you can match on %{foo: y} vs %{bar: y}.