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 into Future itself 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 of Futures be run in parallel if possible). It would also be nice to see a Future variant that supports the concept of retry/repeat out of the box, something like a RestartableFuture.
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?