Inside Rust's Async Transform
blag.nemo157.com
Inside Rust's Async Transform
1–10 of 84 posts
Re: Inside Rust's Async Transform
#2> is very different to other well-known implementations (C# and JavaScript [...]). Instead of performing a CPS-like transform where an async function is split into a series of continuations that are chained together via a Future::then method, Rust instead uses a generator/coroutine transform to turn the function into a state machine.
C# async/await is also very much resumable state machines
Re: Inside Rust's Async Transform
#3Doesn't both JS (via Babel) and C# implement asynchronous functions as state machines in a similar fashion?
Re: Inside Rust's Async Transform
#4[deleted]
Re: Inside Rust's Async Transform
#5Doesn't both JS (via Babel) and C# implement asynchronous functions as state machines in a similar fashion?
According to this blog post, no:
"... performing a CPS-like transform where an async function is split into a series of continuations that are chained together via a Future::then method"
they are referring to c# and js implementation of promises/futures here
Re: Inside Rust's Async Transform
#6I got lost in the weeds fairly quickly with this blog post, why is it that you didn't have to implement Future?
Pinning is required here because your AsyncRead read_to_end returns a future bound by some reference lifetime?
Re: Inside Rust's Async Transform
#7Doesn't both JS (via Babel) and C# implement asynchronous functions as state machines in a similar fashion?
Re: Inside Rust's Async Transform
#8Doesn't both JS (via Babel) and C# implement asynchronous functions as state machines in a similar fashion?
One difference that may exist is that in Rust, async fns don’t immediately execute, they simply create one of these values. I forget if JS and C# do something different, that is, the execute up until the first suspend point. This was one of the major design decisions we’ve made that’s different than other languages.
Re: Inside Rust's Async Transform
#9Doesn't both JS (via Babel) and C# implement asynchronous functions as state machines in a similar fashion?
One difference that may exist is that in Rust, async fns don’t immediately execute, they simply create one of these values. I forget if JS and C# do something different, that is, the execute up until the first suspend point. This was one of the major design decisions we’ve made that’s different than other languages.
No you're correct, C# async/await synchronously executes up to the first yield point. In general the tasks are 'hot' in C#, as opposed to F#'s 'cold' Async type.
Re: Inside Rust's Async Transform
#10Doesn't both JS (via Babel) and C# implement asynchronous functions as state machines in a similar fashion?
One difference that may exist is that in Rust, async fns don’t immediately execute, they simply create one of these values. I forget if JS and C# do something different, that is, the execute up until the first suspend point. This was one of the major design decisions we’ve made that’s different than other languages.
JS starts immediately but even if the function's return value is "ready" synchronously, you can't get its value back synchronously.