This post is full of misinformation. Reposting my reply from Reddit:<p>> what the futures.rs authors decided to do: cram futures.rs into std and add an entire language feature to hide the bloat behind a code generator.<p>First the post establishes a problem with `futures-rs`- combinators and their associated binary bloat. Then in this quote it assumes that the bloat will carry over to the std-based futures used for async/await, even though the express purpose of std futures and async/await is to <i>replace</i> combinators with exactly what the author wants- generators.<p>> the rust equivalent would be slightly uglier, because generators can’t have continuation arguments<p>The next thing it assumes will carry over is the thread-local executor. (Or that's how I read it; it's a little unclear- maybe it means tokio's default executor?) But this complaint <i>also</i> doesn't apply to async/await, which has converted to an executor argument (`Waker`) to `Future::poll`, which is again <i>exactly</i> what the author wants- a continuation argument to the generator.<p>> its in no way fancy, but has two significant advantages over async/await. Firstly, it emits a generator without a specific execution engine.<p>><p>> Secondly, Result just works as intended. There’s no need to wrap it in FutureResult because no such type exists.<p>><p>> Lastly, sync is just: [polling and yielding in a loop] so anything that returns Ready/Again is sync. There is no task queue, no singleton, nothing ‘magic’.<p>These last criticisms of futures and async/await are the most baffling. Futures have <i>always</i> been agnostic to the execution engine, even in the 0.1 form, to a greater degree than osaka. The std version of futures <i>already</i> just uses `Result`. And `await` <i>is</i> just polling and yielding in a loop. The task queue is osaka's `yield poll.again(..)`, the (actually non-)singleton is osaka's `poll` argument, and the "magic" is that `poll` is only accessible from manual `Future::poll` impls.<p>This all seems like <i>very</i> surface-level stuff to me- hardly something that would prevent anyone from using async/await on embedded. The execution model is identical. I saw [this tweet](<a href="https://twitter.com/arvidep/status/1092818400798298114" rel="nofollow">https://twitter.com/arvidep/status/1092818400798298114</a>) saying "you cannot create a push based executor" and [this tweet](<a href="https://twitter.com/arvidep/status/1092823133390864385" rel="nofollow">https://twitter.com/arvidep/status/1092823133390864385</a>) saying "any [Future-based] alternatives need to look like tokio," but it's unclear to me exactly what is changing here, compared to existing embedded uses of async/await.