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 find it too magical to be necessary, but I can see how it might be useful. This can be achieved with a wrapper, but will then require you to wrap every future, which is not too convenient
16 Comments
renegadespork@lemmy.jelliefrontier.net · 11 pts · 147d
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.
orclev@lemmy.world · 1 pts · 147d
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.BB_C@programming.dev · 2 pts · 147d
you know
Futureis a trait, right?orclev@lemmy.world · 2 pts · 146d
Yes, and? It defines the API all the runtimes conform to.
BB_C@programming.dev · 1 pts · 146d
Stating the obvious: a trait is type class you implement for types. It's not something you can "pin metadata" (or any data) to.
orclev@lemmy.world · 3 pts · 146d
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.
BB_C@programming.dev · 1 pts · 146d
where are you going to "pin metadata"?
sukhmel@programming.dev · 3 pts · 146d
I think, they mean:
I find it too magical to be necessary, but I can see how it might be useful. This can be achieved with a wrapper, but will then require you to wrap every future, which is not too convenient
BB_C@programming.dev · -4 pts · 147d
May I suggest creating blog.rustfoundation.org where such mostly useless content can be published?!
Wow, thank god someone asked around and wrote that down.