Comment by AlotOfReading
3 months ago
The meaningful distinction seems to me seems to be the temporal guarantees of execution, not the call structure. Imagine a sequence of async functions that are sleep sorted to execute 1 day apart. A sufficiently smart compiler could compile those to the sync equivalent because it can see the ordering. Similarly, imagine an async runtime that just calls everything synchronously. I've BS'd an interview with that one before.
The "sync guarantees" don't really exist either. If you have a(); b(); the compiler may very well reorder them to b(); a(); and give you similar issues as async. It may elide a() entirely (and reclaim the call structures), or the effects of a() might not be visible to b() yet. Synchronous functions also can and do suspend with all the associated issues of async. That comes up frequently in cryptography, kernel, and real time code.
My comment was really about language semantics. Compilers should respect the semantics and, for instance, only re-order a(); and b(); if there is no data dependency between them and therefore no consequence to exchanging them. But that's in theory: all abstractions leak.