One thing I’m struggling with is finding blog posts which show how to do async now, as opposed to ideas for how async could be improved or done differently. Where’s the best pragmatist’s guide to async rust in 2024?
For example, do you think it’s better to write “async fn” (call this the high level api) and make them fairly small and contained or is it better to impl Future and use enum Poll for low level control of higher level abstract computations (I.e. the one and only point of Async is “Pending”)?
(Hopefully I made sense) — high level API on low level components, or low level API on high level components, or something else?
is a future a structure or a function or both (trajectory?)
I find the difference between concurrency and parallelism is too subtle to be really satisfyingly / obviously accurate or useful. Might there be a better way to separate or rename these concepts to better convey how they are different?
There are more questions, I wonder if you can show us how to write runtime agnostic async code today (admitting the ecosystem has holes, and setting aside how to solve every problem with async rust, how do we practitioners right now future proof our async code to avoid getting overfit / stuck on the details of the Tokio runtime?)
Sry for long comment, no worries if you’re busy, just ideas for questions to optionally write about
> For example, do you think it’s better to write “async fn” (call this the high level api) and make them fairly small and contained or is it better to impl Future and use enum Poll for low level control of higher level abstract computations (I.e. the one and only point of Async is “Pending”)?
You would almost never implement a future unless you needed that specific future for a purpose
> is a future a structure or a function or both (trajectory?)
It is a structure that implements certain traits.
> I find the difference between concurrency and parallelism is too subtle to be really satisfyingly / obviously accurate or useful. Might there be a better way to separate or rename these concepts to better convey how they are different?
The difference between concurrency and paralellism is way bigger than rust. I'd suggest just learning the concept.
> There are more questions, I wonder if you can show us how to write runtime agnostic async code today (admitting the ecosystem has holes, and setting aside how to solve every problem with async rust, how do we practitioners right now future proof our async code to avoid getting overfit / stuck on the details of the Tokio runtime?)
There is no runtime agnostic way to write things in rust because the runtim handlers are different. When a future can be make progress, the runtime needs to handle there internals. This means that crates are typically written using the core structures of a single runtime. The only thing that is "guaranteed" in rust is what a Future "can do" and the async/await interface.
As for changing runtimes, if you don't know enough to discern between runtimes, you should just use Tokio. It's the standard. You wont need to change.
For example, do you think it’s better to write “async fn” (call this the high level api) and make them fairly small and contained or is it better to impl Future and use enum Poll for low level control of higher level abstract computations (I.e. the one and only point of Async is “Pending”)?
(Hopefully I made sense) — high level API on low level components, or low level API on high level components, or something else?
is a future a structure or a function or both (trajectory?)
I find the difference between concurrency and parallelism is too subtle to be really satisfyingly / obviously accurate or useful. Might there be a better way to separate or rename these concepts to better convey how they are different?
There are more questions, I wonder if you can show us how to write runtime agnostic async code today (admitting the ecosystem has holes, and setting aside how to solve every problem with async rust, how do we practitioners right now future proof our async code to avoid getting overfit / stuck on the details of the Tokio runtime?)
Sry for long comment, no worries if you’re busy, just ideas for questions to optionally write about