Within the Rust Project, we can work towards stabilizing long-awaited features such as async functions in dyn traits, or improving compiler errors for issues with, for example, lifetimes and async code. We can include fundamental async library traits and functions within std, enabling a more cohesive async ecosystem.
I’m glad they’re focusing on this. A more standardized async has been a long time coming, and the prerequisite to improving its ergonomics and readability imo.
In my opinion the two biggest problems with async today are that it’s missing a standardized API for spawning new threads/tasks (forcing you into picking a particular implementation for something that is pretty fundamental to using async), and there’s no convenient (to say nothing of standardized) way to pin metadata to a
Future(E.G. an execution context, or thread-local equivalent). While you can certainly just pass an execution context object around manually it would be nice if there was something baked intoFutureitself that would prevent that context from cropping up in every method signature.The new nightly only (and feature flag gated)
std::future::join!macro is a nice start, but there’s still more needed (E.G. a mechanism to signal to the underlying implementation that you would prefer some set ofFutures be run in parallel if possible). It would also be nice to see aFuturevariant that supports the concept of retry/repeat out of the box, something like aRestartableFuture.you know
Futureis a trait, right?Yes, and? It defines the API all the runtimes conform to.
Stating the obvious: a trait is type class you implement for types. It’s not something you can “pin metadata” (or any data) to.
It’s an API, if you add methods to it then the implementations will support that. That is in fact the entire point of a trait.
May I suggest creating blog.rustfoundation.org where such mostly useless content can be published?!
Faster compilation would be useful.
Wow, thank god someone asked around and wrote that down.
