Rust 1.82.0
blog.rust-lang.org
blog.rust-lang.org
- Precise lifetime capturing in impl Trait
- Syntax for direct raw pointer creation
- Unsafe blocks for declaring extern items, and declaring extern items safe
- Fixed unsafe attributes to actually use unsafe syntax
- Omitting empty types in pattern matching
- Guarantees about NaN semantics and floats in const expressions
There is even more trait system improvements coming in the upcoming releases, some features that should especially help bringing the async ecosystem forward from its "MVP slump" it has been in for years. It feels like a bunch of work that has been slowly cooking for years, is landing these days.
However, I'm especially stoked about the &mut support in const expressions, and many accompanying APIs that then can be const-ifyed. That is going to being released next month in 1.83.0.
Can you clarify this point in more detail, please? I've paused my work with Rust because async has been a constant struggle and I never worked with it for such long periods so as to learn all the non-obvious idioms.
The final enabler of async in traits, "impl Trait in traits" is likely to land during Q1 of 2025. (impl Trait is a way to hide an anonymous type behind an interface and give it a name, which turns out to be important because much of the Futures used in async code are auto-generated by the compiler, and thus anonymous.)
As traits are a core means of abstraction in Rust, this has seriously hamstrung the usability of async. Also, because of this, the standard library hasn't been able to provide a standard set of traits that would unify the async ecosystem. That's why the ecosystem is in an balkanized state at the moment, Tokio being the largest faction.
There are other usability problems too: first being the inflexibility of the current trait system, preventing writing code that is generic over single-threaded and multi-threaded async runtimes. This is going to be fixed by "function return type notation in where clauses", also likely to land during Q1 of 2025.
These fixes are already going to be a huge boon to the async ecosystem.
Finally, we are maybe going to see ergonomic improvements in the Pinned references/pointers. Of what kind, and when, is still very much an open question, but there is an active discussion around that. But if you are not writing low-level async building blocks but "just" plumbing using existing libraries and frameworks, Pin isn't going to kill you, so this is more for improving ergonomics of the advanced use-cases.
All in all, I think that one year from now on, the situation around async will be a whole lot better than now.
1. What was the workaround for the lack of `impl Trait` in traits? Was it the dreaded pinned boxed return values?
2. How does adding that make async objectively better? I mean yes, the boxxed pinned stuff was kinda sorta ugly but also something you get used to. I don't remember that being too much trouble.
3. RE: standard set of traits, are you convinced that this is the reason we have the split async ecosystem? I honestly never delved deep enough to understand the reasoning behind why separate groups of people figured to do different async runtimes. I suppose it never occurred to me it was because of the lack of the standard set of traits.
4. RE: `Pin`, exactly, it never "killed" me indeed, though I did grumble a fair amount of times about it and I would be very happy if the dancing around Pin / Box / Pin+Box is at least reduced (and I believe the latest Rust release had something to say about it).
Finally, do you believe that the gradual improvements in Rust that pertain to the traits and GATs done in the last months are really going to unify the async ecosystem? I wish I could believe it would but it was several years and a very heavy investment from the several async library communities; if Rust core attempts to make this list of standard traits then maybe everyone would just ignore them (and I hope that does not happen).
1. Yes! There was even a semi-official solution for that: https://github.com/rust-lang/impl-trait-utils
2. No need for boxing and allocations and pinning the box, and dyn also limits the traits to the dyn-compatible ones. But yeah, maybe it wasn't too bad before?
3. I'm not convinced it's THE reason, but that is A reason. Besides that, there's at least the split between io_uring (completion) style APIs and epoll (readiness) style APIs. How to square that circle seems to be like an open question... Then there's the split between multi-threaded runtimes that require Send/Sync and single-threaded ones. Then finally, there is no standardized way to spawn new independent tasks, so every runtime invents their own. We'll see, but at least the current developments (impl Traits in traits and return type notation) would allow there to be a larger set of compatible types and traits. Whether that will solve the whole balkanization issue is beyond me, but at least it fill in some gaps.
4. Yeah, that seems to be a hard problem. Niko Matsakis and withoutboats have been blogging about some thoughts and designs to fix the ergonomics, and I think they will get better, but it might take years.
I think the situation will slowly improve, but indeed it seems like it'll take years. But at least now we have another "round" of stabilized features that will remedy some of the issues. Maybe, after playing some more with those new tools, we'll have a better understanding about the remaining ones, and what is really needed to fix them.