> Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything?
No. There's no way around understanding that some of your code will run now, and some will run later. It's imperative to understand this in places where you mix sync and async code. It's not possible to avoid mixing them, after all, the async functions have to be called by something.
You could hide all async in a procedural layer if you accepted the constraint that once an async call starts, none of your own code will run until it returns. It wouldn't block the browser or OS, but it would block you. That's the only way to abstract async away, but that's a constraint I think most people would not be willing to accept.
> ...people still kind of want to write code that does one thing after another
I have no choice in the matter. I can't make use of the result of a REST call until I actually have the result.
But, you're right at a fundamental level as well; people do want strict ordering and simple to understand execution with predictable results. The ideal is being able to read a piece of code and see & understand everything about it based on the function you're looking at, and not a bunch of context outside that function. It's the reason functional programming paradigms are favored by so many.
No. Making it look imperative and being abstracted away are two different things.
Co-routines are not imperative, and you cannot treat them as though they are, you still have to understand they're async to use them at all. That is not "abstracted away", that is syntactic sugar.
Furthermore, this syntactic sugar only works locally when examining your coroutines, or promises, or asyc/await code. You still have to trigger that async code from somewhere, and the place it's triggered is always mixing sync and async code, so you can't sugar coat all of it.
There is no getting around knowing and thinking about the async factors when writing async code. You cannot hide it with coroutines or anything else.
> You could hide all async in a procedural layer if you accepted the constraint that once an async call starts, none of your own code will run until it returns. It wouldn't block the browser or OS, but it would block you ... I have no choice in the matter. I can't make use of the result of a REST call until I actually have the result.
The core.async library for Clojure makes the code look imperative, but handles locking and selecting threads to run under-the-covers ... you may find it an interesting compromise
No. There's no way around understanding that some of your code will run now, and some will run later. It's imperative to understand this in places where you mix sync and async code. It's not possible to avoid mixing them, after all, the async functions have to be called by something.
You could hide all async in a procedural layer if you accepted the constraint that once an async call starts, none of your own code will run until it returns. It wouldn't block the browser or OS, but it would block you. That's the only way to abstract async away, but that's a constraint I think most people would not be willing to accept.
> ...people still kind of want to write code that does one thing after another
I have no choice in the matter. I can't make use of the result of a REST call until I actually have the result.
But, you're right at a fundamental level as well; people do want strict ordering and simple to understand execution with predictable results. The ideal is being able to read a piece of code and see & understand everything about it based on the function you're looking at, and not a bunch of context outside that function. It's the reason functional programming paradigms are favored by so many.