Rust 1.75.0 | Hacker News Reader

Rust 1.75.0

blog.rust-lang.org

62 pointsdemurgos14 comments

I know a lot of people are enthusiastic about async traits, but for me, it's "We can return 'impl MyTrait' from trait methods! Finally!"

There were a bunch of instances in my code where I really wanted to specify "this trait returns an arbitrary iterator of X" instead of "this trait returns Vec<X>". It's nice to finally be able to write it that way.

I was excited for this one to replace a bunch of single type Box<dyn Trait> returns, but there are still quite a few limitations using -> impl Trait in traits in general. It's still discouraged to use them in public APIs: https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-trait...

We have to be careful when using impl trait in return position in public APIs.

The opaqueness means that the consumer of the API cannot name the type and cannot store it inside of a struct (without making it generic (moving the issue one level higher), or boxing).

I will consider this feature complete once we get the ability to name these opaque types, via a type alias impl trait.

To be fair the syntactic sugar that is impl Trait could be done as a generic parameter with restrictions as I understand it? The concept of impl Trait for parameters and returns seems intricately tied to Future trait. It’s interesting to see some of the inner workings of the compiler team in the process of this be in my view somewhat conservative on the feature, rightfully so! I love the language and the compiler. The stewards of it seem careful and that’s in my view a good thing.

Maybe the limitations and logic around this ITRPiT (?) stuff make tons of sense to anyone who’s used to the Rust async typestack, but to an outsider this is almost completely incomprehensible gibberish, even after reading the fairly detailed blog posts about it. I like the idea of Rust, like many people do, but when I actually see convoluted language features like these it makes me think this is not a serious language meant to empower everyday users like it says on the label. I think at this point I’d almost rather use OCaml or Haskell.

Well, if you don't use the language, of course a more advanced feature would be gibberish. You'd have to actually learn the language from the beginning, not at the middle or end which is basically what this blog post is talking about.

All that the blog post is saying is that if you have a trait A, you can make a function where it will return something that implements A, from another trait B. It's a way to make traits depend on another. It's similar to if you have an interface called Drivable (and classes that implement it, like Car or Bike) then you can make a function like `drive` that returns something that implements Drivable, inside some other trait. All that `async fn` is is syntactic sugar for something that implements the Future trait.

It’s not returning impl trait that is confusing, but the limitations surrounding it. Why shouldn’t there be send by default, why is send so important to the discussion? Why do we need to worry about GATs in this context? Why shouldn’t we expose this to users of our traits yet?

Why isn’t async straightforward? It seems like a fairly fundamental aspect of a language and a key differentiator. I suppose it has something to do with capturing a reference to self, but I don’t think I understood that bit either. And why are static impl traits supported but not dynamic?

At the end of the day this feature is simply inaccessible. I’m not a complete outsider, I understand why it’s useful to return a future of result user record, or the difference between impl trait and dyn trait.

There are fairly technical answers to these questions, and people have attempted to offer them, but I suppose I would need a master class to get me to where I could understand the answers.

That isn’t the case for async in most languages and I’m not really clear why people didn’t put a bit more care into the async API for Rust.

If your language requires an expert to use a fundamental feature, I feel there is a gap in the design principles.

I see, thought you didn't have experience with Rust, my mistake. To be honest I think most people are using Rust async just fine, with the async_trait crate, and Rust in general simply because most aren't doing anything too advanced or use workarounds where needed, via crates, syntactic desugaring, or otherwise. For example, I use Rust primarily for my backend web server via Axum, and I haven't really felt a need to stress too much about async, everything I need to work just works. Every language has its faults, people simply work around them to Get Shit Done.

> async fn and return-position impl Trait in traits

Does this get rid of this: https://crates.io/crates/async-trait ?

Yes

Yes if you use generics, no if you use trait objects (`dyn Trait`). These new features are implemented similarly to a hidden associated type and are not object-safe. There were some discussions about object safety, but it's a tough issue to fix while remaining explicit about allocations.

With Solana pumping, I am once again getting lots of opportunities to use Rust in my freelance work. It's nice to see Rust slowly creep up into anything, especially outside of system / low level development. By this rate we'll use Rust in webdev and app development and I'm getting excited.

Is Solana that you mention this https://solana.com/ ?

Most likely, as Solana and some other cryptocurrencies use Rust.

Reply on news.ycombinator.com