Async and Await in Rust: a full proposal
boats.gitlab.io
Async and Await in Rust: a full proposal
1–10 of 196 posts
Re: Async and Await in Rust: a full proposal
#2Usually we add notes like (2016) to old articles. In this case it would be appropriate to add (April 2018) to the title given how fast the futures ecosystem is moving in Rust.
Re: Async and Await in Rust: a full proposal
#3Usually we add notes like (2016) to old articles. In this case it would be appropriate to add (April 2018) to the title given how fast the futures ecosystem is moving in Rust.
2018 is assumed
Re: Async and Await in Rust: a full proposal
#4Re: Async and Await in Rust: a full proposal
#5I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call.
If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.
Re: Async and Await in Rust: a full proposal
#6I want to reflect on that this is still done without any garbage collector.
Re: Async and Await in Rust: a full proposal
#7I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.
Async being a “default” function type doesn’t make much sense unless you’re doing io. If you’re just computing, you often can’t proceed without the result and want to proceed as soon as you have the result—i.e. blocking. Both are critical to getting good performance.
I’m curious if discerning which is the best type is possible to tool automatically with static or tracing analysis.
Re: Async and Await in Rust: a full proposal
#8This is exciting. It allows programmers to model their problems in code that fully accounts for the parallelism.
For comparison, here is async/await in Zig: https://ziglang.org/documentation/master/#Coroutines
Zig decided to go the other way - when you async call a function, it does eagerly evaluate until the first suspend point. This is less overhead than immediately suspending, plus it removes the dependency of the language feature on a userland event loop. Users who want the immediate suspend feature can call a userland utility method of the event loop which suspends and then tail calls the async function in question.
Re: Async and Await in Rust: a full proposal
#9I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.
Having made "async" the default, you've just returned to regular threading, which is what we should have stuck with all along. The thread model is actually pretty useful, the pitfalls are well understood, and the tooling very mature.
Re: Async and Await in Rust: a full proposal
#10I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.
One of the biggest advantages of await is that it's explicit. Otherwise literally any function call can block, and whether or not it blocks is dependent on the body of the function so you can end up with races appearing in random parts of your code because you update a package. It's bad. At that point you might as well just use threads and blocking calls.