Congratulations on releasing 1.0. This will be a huge milestone in making async programming very approachable to newer Rust devs and a solid base to build upon. There's a lot to like about async-std: It keeps things as similar as possible to std, and the general focus on a well-designed public API, relies on small and shared abstractions for library authors (through futures-rs), good documentation from the start, and a very encouraging community attitude. Keep it going :-)
The first example of reading a file in sync vs async really makes me feel like you could have a macro of sorts that just lets you write the sync version and have it generate the async version (assuming you only use the stdlib IO based APIs). Usage of threads could even be converted to tasks, etc.
I'm sure it falls apart in various places, but it would really make async (in Rust) a lot more approachable. At which point you have something very similar to how Go does things, which I think is potentially very nice.
> you could have a macro of sorts that just lets you write the sync version and have it generate the async version
That sounds like a good idea in theory. In practice you will discover that async is a bit different. E.g. you can't have recursive functions, some new lifetime effects will come into play (an async fn returns a Future, and everything that generated Future captures lifetimes of other things).
async/await made async programming in rust definitely a lot more accessible! But at some times the lower layers still leak through and cause some unexpected compilation errors.
Thanks for the explanation. I was curious what specific flaws there would be in such a design, and what you said makes sense. Perhaps something doable with more thought and features to support it in the future!
6 comments
[ 2.8 ms ] story [ 23.2 ms ] thread- https://docs.rs/async-task
- https://docs.rs/crossbeam-deque
The first example of reading a file in sync vs async really makes me feel like you could have a macro of sorts that just lets you write the sync version and have it generate the async version (assuming you only use the stdlib IO based APIs). Usage of threads could even be converted to tasks, etc.
I'm sure it falls apart in various places, but it would really make async (in Rust) a lot more approachable. At which point you have something very similar to how Go does things, which I think is potentially very nice.
That sounds like a good idea in theory. In practice you will discover that async is a bit different. E.g. you can't have recursive functions, some new lifetime effects will come into play (an async fn returns a Future, and everything that generated Future captures lifetimes of other things).
async/await made async programming in rust definitely a lot more accessible! But at some times the lower layers still leak through and cause some unexpected compilation errors.