undefined | Better HN

0 pointsdboreham1y ago0 comments

Agree. If people want to delude themselves that async is useful, that's fine. But don't inflict it on the rest of us by viral propagation throughout the dependency ecosystem.

0 comments

3 comments · 1 top-level

vacuity1y ago· 2 in thread

I claim that async/await is far more basic (/fundamental/simple, not necessarily easy) than most acknowledge, but it should indeed be more composable with sync code. It is a means of interacting with asynchronous phenomena, which underlie the OS-hardware connection. The composability is necessary because no one is going to write a massive state machine for their entire program.

int_19h1y ago

Part the problem is ABI. Fibers are a more sensible approach to async, but as soon as you introduce them, FFI becomes a massive pain (see e.g. Go) in any environment which doesn't have fibers as a first-class primitive that everybody supports.

Promise-based async has the advantage that you can desugar it down to C-compatible ABI.

vacuity1y ago

I think the promise-based model is the ideal model. After reading [1], I'm convinced that it's very close to realizing the underlying state machine ([2]) of the program, and I find that valuable. I agree that fibers are easier to use, but not simpler. I understand that my hard-line approach is not practical everywhere, but at least the async model used by Rust is not just a concession to the C ABI and whatnot, but an important model in its own right. So I think that it is quite sensible, if not practical for most programmers to make sense of :). Add fiber abstractions on top if appropriate, of course.

[1] https://glyph.twistedmatrix.com/2014/02/unyielding.html [2] https://lamport.azurewebsites.net/pubs/state-machine.pdf (read the introduction)

j / k navigate · click thread line to collapse