[zer8k]

> With that said, I can't help but feel that Rust development has noticeably slowed down over the years. Don't get me wrong, I appreciate the hard work behind each release! It's just that, from my totally uninformed bystander perspective, there's been a sharp drop in people working on the language and compiler full-time since around Mozilla layoffs, and Rust still hasn't recovered from that. It's surprising and quite disappointing to see no significant manpower commitment from other corporations using Rust, like Microsoft [2] and Google [3].

They brought this on themselves being Leadership By Community rather than forming a working group to get a standard out. The reason C and C++ got incredibly popular was two fold:

1. There was really no other choice

2. They were rapidly adopted by a wide variety of people, competition led to standardization, and eventually convergence on a few good compilers. `mrustc` is basically the only alternative and it's only REAL use is for an alternative bootstrap story since Rust bootstrapping is still a problem.

The entire story for Rust is rather pathetic because it would appear at every turn they made the wrong choice despite having a lookback of over 50 years of compiler evolution. Which is sad, because Rust does bring a lot of very nice things.

Because the Rust team doesn't want this path (as in, they are not even entertaining the idea) you're left with a relatively small group of very brave volunteers trying to do their best to be The Standard (TM). The hope was that with adoption from Cloudflare/Amazon/Google/Facebook you'd see a similar standardization story. But it seems none of these groups are interested in the compiler itself and instead are just interested in promoting its use.

Stabilization will be a long term concern. The inclusion in the linux kernel is minimal at best, there are some limited use cases in Asahi, etc. The success of Rust is largely mythical rather than reality. The community at large is extremely vocal to the point of zealotry which also is likely driving people off of helping with the effort. There are a lot of very smart compiler developers in the C and C++ world that don't want anything to do with Rust strictly because of it's community.

Finally, it's also possible companies that may contribute more are being driven away by the politics of the core team. There was an unbelievable discussion on whether they should allow Palantir to continue to work with them because they Do Bad Things (TM). While I can respect their opinion on the subject I cannot respect the general lack of professionalism that you see from the team. While these things don't matter with small languages they do matter a lot with big ones. This lack of professionalism bleeds into every part of the language. It's time we stop talking about Rust like it's a toy language that can get away with being edgy and hip. If it wants to survive it needs to make drastic changes towards a model used by nearly every successful language for the last 50 years.

My conclusion is if Rust wants to succeed it needs to standardize, eject every member of the existing team, and aim for a more professional (e.g. not Mozilla's brand of politics) version of itself. Otherwise it's doomed to hobbytown for the rest of its days and C++ will continue to reign supreme.

Side note:

It's nice to see they dropped the politics for this set of release notes. Maybe they're learning.

[dralley]

> They brought this on themselves being Leadership By Community rather than forming a working group to get a standard out.

First of all, the idea that the C++ standards process is some pinnacle of productivity and velocity is endlessly funny to me. Maybe by the time C++26 comes out, all of the features in C++23 might be considered "usable" with more than one compiler. That's saying nothing of the purgatory that certain features have been in for years.

Second, who implements the standards? Google pulled back most of their resources from Clang. Most development on C/C++ compilers is currently done by companies like Microsoft and Red Hat and Intel that have a lot of paying customers relying on those ecosystems. That's a function of time and penetration, not whether there's a "committee" involved.

Third, politics exist in C++ as well. People snipe at each other in public and on private mailing lists and conferences. They are not immune from "unprofessionalism".

[qsdf38100]

I don’t get why c++ has to be bad for rust to be a good language.

[dralley]

I'm not criticizing C++ as such, I'm criticizing the idea that a standards committee is the reason that C++ develops quickly (and that detail isn't even obviously true), or that lack of a standards committee is the reason Rust doesn't (which also isn't obviously true).

The whole line of argument is just absurd. Look at Go or Python or Ruby - none of them are ruled by a standards committee, and all of them are very popular and see plenty of development. And frankly I don't think Rust actually develops slower than C++ does. Rust delivers features every 6 weeks rather than every 3 years, so it can be hard to tell just how much progress has actually been made even when it is actually quite a lot.

[duped]

Why do people care so much about a "standard?" Multiple implementations are not actually a Good Idea nor does "The Standard" help you on the ground as a programmer.

I also don't really see zealotry anymore. I see new projects being written in Rust left and right, and C++ developers bitching about it because they don't want to learn it or have been so scarred by moderately advanced language features implemented poorly they think Rust does it poorly too.

[qsdf38100]

C++ developers don’t "bitch" about rust, in my experience. They either get interested in rust or ignore it. The drama seems to always come from the rust evengelists, that won’t accept someone who don’t agree c++ should be banned and rust is the savior language…

[pdimitar]

It's legitimately baffling if you actually believe that.

99% of all programmers just want their chosen tool to succeed.

Consider that you might have been influenced by rage-baiting trolls. That's understandable and it happened to all of us at one point.

Don't judge a community by the 0.1% bad apples. Every community has them.

[qsdf38100]

Sorry, it's baffling if I believe what exactly? That rust supremacists are more than 0.1% of the community? Then I can only speak of what I hear from it, and my experience is that more often than not, the discussion ends up with an implied ultimatum: either you agree that using c++ instead of rust is irresponsible and wrong, either you are being "a part of the problem" and should not be programming. I'd like to be wrong and happened to have came across mostly bad apples.

[pdimitar]

> The drama seems to always come from the rust evengelists, that won’t accept someone who don’t agree c++ should be banned and rust is the savior language…

This. This is what I find baffling that somebody can believe in. Every community has the 0.1% of insufferable zealots and Rust is no exception.

I worked with absolutely brilliant Rust programmers that made me question if I know anything at all about programming in general -- and I have 21.5 years of experience.

I keep seeing your sentiment expressed in a number of Rust threads which becomes more and more confusing with time because I scarcely see anyone at all advocate zealously for Rust but I am seeing plenty of people like you who keep insisting that Rust fans are torturing them. :D

It gets funny at one point.

I mean, try to be more data-driven. Scan the last 5 big Rust threads and just try to do basic sentiment analysis. I have, and I am mostly seeing very balanced and curious debates. I haven't noticed any zealotry. Last time I noticed people being as annoying was I think somewhere back in 2018.

[slikrick]

yes, the language you use to describe something completely wrong is baffling.

you have been tricked into being mad at something that literally doesn't matter.

[qsdf38100]

Me? mad? Hmmm.

What about your language? And his?

"Bitching", "baffling", "rage-baiting trolls", "completely wrong", "literally doesn't matter".

My language: "in my experience", "more often than not", "I'd like to be wrong and happened to have came across mostly bad apples."

So, I'm not the one who is "mad" and "bitching" here. You are the one mad at me.

Who is being tricked? Sounds like you are tricking yourself.

[dgb23]

> There was an unbelievable discussion on whether they should allow Palantir to continue to work with them because they Do Bad Things (TM).

Well, since it's community driven, this makes perfect sense. Freedom of association and all.

[inferiorhuman]

  politics

That's a lot of words for "I don't like the politics of the people contributing to rust" with a side of "there must be a lot of people like me and they're all very smart". If I'm honest, that doesn't seem terribly professional or realistic.

As someone who's not a compiler guru, I've found contributing to rust (whether rustc or third party crates) to be generally frictionless and overall a pleasant process. It's great to not have to deal with the drama surrounding so many other projects (EGCS anyone?). Quite frankly I'm glad there's no need to hold your nose and put up with RMS' antics.

  eject every member of the existing team

What? Ejecting everyone who's built the tool you like because you don't like their politics is preposterous on its face and wildly unprofessional.

  Rust bootstrapping is still a problem

What?

[Hirrolot]

Since I entered Rust (circa 2018-2019) and async/.await was stabilized, I started to lose my expectations on the growth of the language. Almost every language issue I wanted to be resolved is still unresolved (besides GATs, which are great but took a really long time to be shipped). Meanwhile, the community doesn't cease to perpetually endorse the language; you literally see top-scoring posts like "I felt in love with Rust, can't stop loving Rust, it's so wonderful" every month or so on r/rust, a lot of reaffirming articles expounding on the "success" of the language, collective exultation when it's again most loved on SO, etc.

The current situation with the language is somewhat sad.

[kibwen]

> Meanwhile, the community doesn't cease to perpetually endorse the language

I can't speak for you, but I endorse Rust because I like the language as it exists, not as it might exist in the future, and it seems safe to assume that the other people endorsing it feel the same way, and that people who feel differently are not (and should not be) endorsing Rust. As far as my use cases are concerned, there's no language feature that Rust is missing or that would significantly improve my life (although I suppose inline const would be nice).

(And as far as tooling features go, the only thing that I want is sandboxed builds.)

[howinteresting]

Clearly the state of the language post-async/await is good enough that tens of billions of dollars, probably more, are riding on it. There's still lots that needs to be done but the language is in pretty good shape today.

Why shouldn't people fall in love with Rust and post about it? I fell in love with Rust before NLL even.

[Mawr]

> you literally see top-scoring posts like "I felt in love with Rust, can't stop loving Rust, it's so wonderful" every month or so on r/rust

That's expected on any forum dedicated to <subject>. People tend to only specifically seek out communities around subjects they like, not dislike.

[estebank]

Could you expand on what language issues you want resolved that the project isn't addressing?

[Hirrolot]

Async traits, async `Drop`, TAITs, variadic generics (unlikely they will every be implemented), generic closures, optional/named parameters, anonymous enums. These are the first that came to my mind.

[estebank]

Thank you for the list! That's useful for me to understand what we might not be actively working on that people find frustrating.

- Async traits: coming soon https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizin..., actively in development (and has been for a while now, please don't confuse "this problem is hard and taking a long time" with "we don't care about this problem" https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%...).

- async `Drop`: there have been multiple "false-starts", trying to come up with an acceptable design. We don't have a good answer for this at the moment. It is unknown to me how long it might take for us to figure it out.

- TAITs: same as async traits. It'll likely land after async fn in traits, but it's part of the same design and implementation effort.

- variadic generics (unlikely they will every be implemented): agree with your assessment, at least in the short to medium term.

- generic closures: same as above.

- optional/named parameters: I believe that this feature as such might never exist in rust but think that a combination of structural structs (`struct { bar: usize, baz: usize }`) and/or struct literal inference (`let x: S = _ { bar: 1, baz: 2 }`) and default const values in structs (`struct S { foo: usize = 42, bar: usize }`/`S { bar: 0, .. }`) would be more generally useful and would nicely cater to this use case (`foo(_ { bar: 42, .. }`).

- anonymous enums: I want this as well, but it interacts poorly with type parameters and automatic type upcasting (if you have `A | B` can you convert it into `A | B | C`? Does it need syntax? What about `Result<(), ()> | Option<()> | Result<i32, ()>`? If you have a function that returns that, what does `return Err(())` do?). Type downcasting could be done by forcing a match expression on the value. Whether `A | B` should `impl T` if `A: T, B: T` is an open question. I want to push for a solution here in the coming year.

[jenadine]

> TAITs

I personally find these 4 letter acronyms difficult to lookup and understand. One of the T is probably "trait", but I always forget.

[estebank]

Sorry, the names we use within the team are not meant to be used in user facing communications, but it is easy to forget that not everyone I talk to isn't in the team :)

TAIT stands for `type Alias = impl Trait;`, which would let you do something like

    type Alias = impl Display;
    fn foo() -> Alias {
        42
    }
    fn bar() -> Alias {
        0
    }
    fn main() {
        let x: Alias = if rand() > .5 {
            foo()
        } else {
            bar()
        };
    }

If you changed bar to return a &str, for example, that would be a compile error.

There's also the related

- RPIT, "return position impl trait" (we already have this)

- RPITIT, "return position impl trait in traits" (the foundation for async unctions in traits, `trait T { fn foo() -> impl Trait; }`)

- AFIT, "async functions in traits"

No, you shouldn't need to know what these things mean, beyond them "just working" in terms of what you would expect from writing impl Trait in different places.

[Hirrolot]

Thanks for your comprehensive answer, it's really nice to see that async traits and etc. might be coming soon.