alt Hacker NewsI remember being so mad years ago, coming from a pure CS background, when it dawned on me that async await was “mere” control flow and not actual parallelism.
It’s why I feel go (with go routines being the norm) is one of the few imperative languages that was designed vs. filling out a bunch of historical constraints (apologies this is not meant to trigger a language debate, just an idiosyncratic thought)
Replies
aw1621107 • today at 2:02 AM
> vs. filling out a bunch of historical constraints
Do you mind elaborating on this? I don't understand what you're trying to get at.
➕ show 1 reply
Being mere control flow is a good thing: some async/await implementations are just desugared into a state machine anyways, and it totally works on a single thread. Early async/await in Python was just a small generalization of its existing generator mechanism, and nobody would think generators in Python enables parallelism: it was always a control flow construct. This cleanly demonstrates the separation between the concepts of concurrency versus parallelism.
And of course go routines and channels can also be desugared into mere control flow. That’s how ClojureScript does async.