In the Hacker News discussion about async/await hitting stable, a commenter mentioned the "synchronous concurrency paradigm", as exemplified by the languages Esterel and Céu.
I have not yet had the time to read the Céu paper, but from what I can tell it actually looks somewhat similar to Rust's async/await semantics. I originally thought that the models might be isomorphic, i.e., that "trails" in Céu might be semantically equivalent to async fns in Rust, but the commenter said that Céu's ordering guarantees are fundamental to its model, whereas execution ordering is not required to be deterministic in Rust.
I haven't written a Reactor or Executor of my own, but I would expect it to be possible (perhaps even easy) to implement a Reactor that would ensure deterministic ordering by only marking a Future as ready to poll when it is the next polling operation's "turn". Alternatively, an Executor could ensure the ordering by simply halting execution entirely until the Future whose "turn" it is has been marked ready, and then polling only that Future.
I think this is an interesting avenue of exploration because, prior to hearing about synchronous concurrency, I was unaware of any prior art comparable to Rust's async design providing asynchronous semantics without requiring heap allocation and/or green threading. If Rust's async/await can be shown to model Céu's trails, then Céu/Esterel research results could be applied to Rust as well.
Would anyone be interested in helping me explore this connection and attempt to formalize the mapping from Rust's functionality to Céu's? Alternatively, does anyone know of any discrepancies in the models that make them incompatible?