4 ms·

A lot of that pain could have been avoided if the language had better primitives for async in the std or in the futures crate. Like a trait that executor must i

by Sytten 3y ago

A lot of that pain could have been avoided if the language had better primitives for async in the std or in the futures crate. Like a trait that executor must implement and a "default" blocking executor to execute async code from sync. Right now even building a library that support multiple async runtimes is a PITA, I have done it a couple times. So you end up supporting either just tokio and maybe async-std.

JoshTriplett 3y ago
> A lot of that pain could have been avoided if the language had better primitives for async in the std or in the futures crate. Like a trait that executor must implement and a "default" blocking executor to execute async code from sync. This is one of the goals of the async working group. Hopefully, when ready, that'll make it possible to swap out async runtimes underneath arbitrary code without issues.
half-kh-hacker 3y ago
so it's clear to non-Rust devs, we do have basic primitives for "running async code from sync": https://docs.rs/futures/latest/futures/executor/fn.block_on.html https://docs.rs/futures/latest/futures/executor/fn.block_on.... imagine you have an: async fn do_things() -> Something { /* ... */ } you can: use futures::executor::block_on; fn my_normal_code() { let something = block_on(do_things()); } but this does get messy if the async code you're running isn't runtime-agnostic :(
- colinsane 3y ago
  > You can break the chain by commanding the entire runtime to block on the completion of a future, but you probably shouldn’t do this pervasively since it isn’t composable. If a function blocks on a future, and that future calls a function that blocks on a future, congrats! The runtime panics! article says you can panic if you use the pattern you show. specifically, if you call `my_normal_code()` from an async context. is the author just talking about a quirk in tokio? or is this sort of wrapping intrinsically dangerous somehow?
  - skitter 3y ago
    It's not intrinsic to async functions; you can block on a future inside another future via e.g. pollster or even manual polling.
- 0xDEF 3y ago
  In the .Net/C# world library users just expect that the library has implemented both DoThings() and DoThingsAsync(). However that is easier said that done because many of the foundational low-level IO APIs were implemented by Microsoft that first implemented IoMethod() and then implemented IoMethodAsync() when async/await became a thing in C#.

by Sytten 3y ago

JoshTriplett 3y ago

> A lot of that pain could have been avoided if the language had better primitives for async in the std or in the futures crate. Like a trait that executor must implement and a "default" blocking executor to execute async code from sync. This is one of the goals of the async working group. Hopefully, when ready, that'll make it possible to swap out async runtimes underneath arbitrary code without issues.

half-kh-hacker 3y ago

so it's clear to non-Rust devs, we do have basic primitives for "running async code from sync": https://docs.rs/futures/latest/futures/executor/fn.block_on.html https://docs.rs/futures/latest/futures/executor/fn.block_on.... imagine you have an: async fn do_things() -> Something { /* ... */ } you can: use futures::executor::block_on; fn my_normal_code() { let something = block_on(do_things()); } but this does get messy if the async code you're running isn't runtime-agnostic :(

colinsane 3y ago
> You can break the chain by commanding the entire runtime to block on the completion of a future, but you probably shouldn’t do this pervasively since it isn’t composable. If a function blocks on a future, and that future calls a function that blocks on a future, congrats! The runtime panics! article says you can panic if you use the pattern you show. specifically, if you call `my_normal_code()` from an async context. is the author just talking about a quirk in tokio? or is this sort of wrapping intrinsically dangerous somehow?
- skitter 3y ago
  It's not intrinsic to async functions; you can block on a future inside another future via e.g. pollster or even manual polling.
0xDEF 3y ago
In the .Net/C# world library users just expect that the library has implemented both DoThings() and DoThingsAsync(). However that is easier said that done because many of the foundational low-level IO APIs were implemented by Microsoft that first implemented IoMethod() and then implemented IoMethodAsync() when async/await became a thing in C#.