"But if your typey spidey senses are tingling, it’s for good reason: with promises, your whole program has to be transformed to return promises-for-values instead of values anywhere it would block."
(Or lifted into a monad).
To me, that's the big issue with a lot of the concurrency/react abstractions en-vogue now: you are programming indirectly, or more precisely you are programming in a specific (async) architectural style, but trying to express this in a call/return architectural style (that includes methods and FP functions).
Depending on where you are, that often means your actual domain code is hidden inside a lot of maps() or flatMaps(). The first problem is that your domain code really should be primary, and your architectural support code as hidden as possible. The second (but probably not last) problem is that you can easily have multiple of these "lifts", for example another for error handling with Maybe. At some point, it just piles up and the actual domain code is completely swamped.
async/await is sort of the high (or low depending on your POV) point of this approach of mapping other architectural styles to call/return: you just write your code as normal call/return, with normal control flow, and just two little annotations lift everything to a completely different architectural style.
On the one hand, it is truly brilliant, hiding almost all the mechanics of the more asynchronous architectural style so that you can just keep writing procedural code as is. On the other hand, maybe it would be better to make it easier to express those alternate architectural styles directly in code.
This seems like another great move in the direction of the latter.
"But if your typey spidey senses are tingling, it’s for good reason: with promises, your whole program has to be transformed to return promises-for-values instead of values anywhere it would block."
(Or lifted into a monad).
To me, that's the big issue with a lot of the concurrency/react abstractions en-vogue now: you are programming indirectly, or more precisely you are programming in a specific (async) architectural style, but trying to express this in a call/return architectural style (that includes methods and FP functions).
Depending on where you are, that often means your actual domain code is hidden inside a lot of maps() or flatMaps(). The first problem is that your domain code really should be primary, and your architectural support code as hidden as possible. The second (but probably not last) problem is that you can easily have multiple of these "lifts", for example another for error handling with Maybe. At some point, it just piles up and the actual domain code is completely swamped.
async/await is sort of the high (or low depending on your POV) point of this approach of mapping other architectural styles to call/return: you just write your code as normal call/return, with normal control flow, and just two little annotations lift everything to a completely different architectural style.
On the one hand, it is truly brilliant, hiding almost all the mechanics of the more asynchronous architectural style so that you can just keep writing procedural code as is. On the other hand, maybe it would be better to make it easier to express those alternate architectural styles directly in code.
This seems like another great move in the direction of the latter.