I don’t think of async await as “making async code act like sync code”.
I see it as adding meta data to a function type (async) and allowing you to attach the result to a given function scope (await).
The key utility of this is to allow you to use functions as a unit of composition, allowing you to leverage their already built tooling (IDE jump to function, stack frame based debugging, input and output types (in:args -> out:return).
Messaging runtimes like Golang and Erlang use an additional composition unit (channels and mailboxes), and do not allow you to follow the “tree of functions” paradigm like async await does. These result in having to follow a network graph of messages and nodes to find out what will happen.
You need to understand you are dealing with an event loop before you use async await. I think this is the issue the author is raising.
I see it as adding meta data to a function type (async) and allowing you to attach the result to a given function scope (await).
The key utility of this is to allow you to use functions as a unit of composition, allowing you to leverage their already built tooling (IDE jump to function, stack frame based debugging, input and output types (in:args -> out:return).
Messaging runtimes like Golang and Erlang use an additional composition unit (channels and mailboxes), and do not allow you to follow the “tree of functions” paradigm like async await does. These result in having to follow a network graph of messages and nodes to find out what will happen.
You need to understand you are dealing with an event loop before you use async await. I think this is the issue the author is raising.