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