I think in retrospect we’ll find async/await added little to the actual organization of async code. Ultimately, it’s just a “cleaner” way of adding arbitrary branch points that can’t be reasoned about in any wholistic way (which should be the primary goal of async constructs).
-
-
It’s not really resource ownership I’m referring to necessarily, but rather analogous to the “just throw it on a thread” thinking in other languages. Ultimately making yield feel “free” leads to performance (and sometimes logic) errors, and dodges the true problems in async code.
-
Node came out, and the myth that single threaded non-blocking code was a cure-all for responsiveness, w/the only caveat being “the pyramid of hell”, which async/await has now saved us from. We can trace so many perf issues to refusing to reason about the async state machine.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.