I don't have any experience with async Rust (but I stuggled a lot with Rust's closures when I dabbled with Rust a while back so I can at least feel the pain the article tries to convey), but one important reason to not build async-await on top of fibers or threads but instead on code transformation (aka 'compiler magic') is 'weird architectures' like WASM, which doesn't have easy access to threading (locked behind COOP/COEP headers), and where the call stack is inaccessible to code running inside the VM.
I didn't quite get the gist of the article though, isn't the whole point of async-await to get rid of passing callback function pointers around? What do closures have to do with async-await in Rust?
I think the article is just... wrong about async and closures. You're right that async Rust simply doesn't deal with them, because (contrary to the article) they're not used in the async compiler transformation.
I think you can implement fibers and continuations in WASM by converting the whole program into a giant switch statement and heap allocating frames. There are a few scheme-to-C compilers that do that I think.
Mind, it is not going to be fast as it is going to be hard to generate efficient code ...
Emscripten actually has an "ASYNCIFY" feature which does exactly that but (AFAIK) down on the WASM level. It also has surprisingly little performance overhead.
Yes, this is pretty much what I had in mind it seems. From a quick read it is not 100% clear whether it supports stackfull coroutines, but as it is designed to support existing blocking C/C++ code, very likely it does.
> What do closures have to do with async-await in Rust?
Well, space _blocking runs blocking code in an async context. It takes a closure as it's argument and if you're in a mixed async/sync platform you will his this function a lot. To deal with it you end up needing to use move. And to use move you need to clone your pointers to the data and manage all that guff.
The alternatives are Arc, deep copies, or use C++ where you will invariably get it wrong and end up with corrupted data and a very bad week (or you don't notice and reply to this comment saying that you do this in C++ and never had a problem)
I didn't quite get the gist of the article though, isn't the whole point of async-await to get rid of passing callback function pointers around? What do closures have to do with async-await in Rust?