What is your program going to work on while it waits for the task? Usually nothing. You need to read some data before analyzing it, etc.
While you wait the OS can switch to other threads.
The only question here is whether you want to return that time to the operating system or to your language runtime.
> they’re just hiding the complexity
async/await feels helpful because you can write normal code again! If else, for loops, etc.
Oh wait that’s also what the UNIX operating system does. It abstracts away all this blocking and context switching so you can write normal code.
> If adding async to a function is too much
The authors point is a good one. You essentially have two languages and classes of functions. The regular version and the async version. Lots of duplication and a tendency for everything to become async.
> a skill issue.
I think you don’t understand process scheduling.
Hang implies there is something you are not responding to.
Let me ask again. What are you imagining your main thread should be doing while it is waiting for essential data?
responding to new inputs means changing state. But your program is already in another. Two separate program execution states are best described by two separate threads.
> crash
Crash early, crash often. If invariants can’t be maintained, don’t pretend otherwise.
And sure, let’s talk about state. If handling multiple states at once is ‘extremely difficult,’ then yes, async/await might not be the best for anyone who panics when their program has to juggle more than one thing. But that's kind of the point.
Async/await is like giving you a leash for your concurrency so you don’t need to wrangle state machines on a pogo stick. But hey, if you’re happier living on the edge of crashville because ‘the OS scheduler will save me,’ who am I to interrupt your Zen?”