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
Other languages have ended up introducing it out of practical necessity, e.g. Go’s contexts, JS execution contexts. Pick your poison, although I expect Rust’s general minimal approach will leave it as extra parameters, Go-style.
It’s not about magic, it’s just not how the abstraction works.
Let’s have a concrete example, poem::web::Data utilizes opentelemetry::context::FutureExt which has the trait methods with_context() and with_current_context(). But where is the data/context actually stored? In the WithContext struct of course. Because there is no such a thing as pinning (meta)data to a trait.
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.
struct SomeFuture; impl Future for SomeFuture { // .... }where are you going to “pin metadata”?
I think, they mean:
pub trait Future { // .... fn put_metadata(...); fn get_metadata(...); }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
Other languages have ended up introducing it out of practical necessity, e.g. Go’s contexts, JS execution contexts. Pick your poison, although I expect Rust’s general minimal approach will leave it as extra parameters, Go-style.
It’s not about magic, it’s just not how the abstraction works.
Let’s have a concrete example, poem::web::Data utilizes opentelemetry::context::FutureExt which has the trait methods
with_context()andwith_current_context(). But where is the data/context actually stored? In theWithContextstruct of course. Because there is no such a thing as pinning (meta)data to a trait.@devnev@lemmy.dbzer0.com ^^