Odpověď na názor

Barvení funkcí (dva světy) je známý problém i z jiných jazyků. Stejně tak problémy ohledně držení mutexů a dalších zdrojů přes yield point. To stejné nastává u async/await modelu v Pythonu i Rustu.

V non-async kontextu se async funkce dají volat jen blokujícím způsobem přes lokální executor. V Rustu https://docs.rs/futures/latest/futures/executor/fn.block_on.html a v Pythonu je to třeba https://docs.python.org/3/library/asyncio-runner.html#asyncio.run - a koukám, že v C++ to je stejné (což mě nepřekvapuje, kdyby existovalo geniální řešení, tak ho ostatní převezmou taky).

Popravdě, ten vygenerovaný handle, korutina nebo Future objekt jsou si ve všech těch jazycích taky hodně podobné. Ve výsledku překladač vytvoří polling generátor a nějakou metodou (await) se provede další krok.

Interní implementace awaiteru v Rustu je taky vtable a taky specifická pro executor - konkrétně https://doc.rust-lang.org/core/task/struct.Waker.html . Jen mi to přijde, že Rust má hezčí abstrakci pomocí waker.wake() :)

Jednu věc jsem z blogu nepochopil, co přesně dělá await_suspend? A jak se to liší od co_await?

Ta analýza struktury pro uložení stavu korutiny dle překladače je ovšem moc zajímavá. Jelikož async Rust používám na malých mikrokontrolerech, tak mě vždycky zajímalo jak je to optimalizované. Ale Rust používá clang, takže to vypadá, že jsem na tom dobře.

Oddělení executoru mimo standard je taky stejné jako v Rustu (Python má batteries included), pro jednoduché funkce to není problém, ale nastává tam problém s nejednotným api pro registraci nových korutin (spawn / schedule) a pro synchronizační promitiva (mutexy, fronty s podporou await), která potřebují podporu svého executoru. V Rustu je několik soupeřících projektů - tokio, async-std, embassy... - což komplikuje přenositelnost kódu (stejně jako v C++?).