Async isnt about ordered operations its about waiting. When you make a database call, you thread can sit there for 50 ms or do something useful. You can outsource rendering work to a child process. You dont have to let infinite loops block events.
We do this daily in real life. It's more efficient for me to have 10 minutes down time at work while I'm waiting for someone else than it is for me to start something else then either get interrupted or finish another task before I respond to the person I'm waiting on.
I work on services where any given endpoint may handle many thousands of requests per second. We don't care about a slight penalty to query the database, because these are very short, and our services return responses on the order of 100 ms.
Maybe these are things you care about in a language like Javascript, but in something statically typed, they just don't seem like a problem.
Fulfil more/other queries.
> ...in something statically typed, they just don't seem like a problem.
What has static typing got to do with asynchronous IO?
If you're running a web server, you can handle another request, then come back to the first one when the data arrives.
* Would we rather burn computing resources (i.e. on new threads) or calendar time+human resources (i.e. on code refactoring)?
Followed closely by:
* And does it even matter for our situation? (i.e. since for many situations getting every last drop of performance out of a system isn't the real obstacle; it's making it do something useful for the end-user or business)
On the data you need to fulfil one client's query. The answer is that you do stuff you need to fulfil other clients queries, until you're ready to come back to the first one.
I don't see what type systems have to do with your comment either. Scala uses asynchronous concurrency primitives (Futures) and it's statically typed.