There are constant efforts to make async easier in all languages. It'll never be as easy as writing synchronous code.
I really don't like futures/promises, I don't know where this abstraction came from.
Callbacks are where it's at. Someone, somewhere has to write callback code; they cannot be got rid of. What works for me is keeping the callback handler as short as possible, this usually means just pushing 'work' onto an async queue that is serviced by one or more threads.
I've found async to be straight forward anytime I've used it. Promise#then is equivalent to callbacks
async/await often requires very little changes compared to synchronous code, whereas reworking a program into callbacks is much more impactful. & the async/await compilation process tends to produce better performance in addition to this. My first async/await work was a few years ago to increase a data importer's performance by an order of magnitude compared to the blocking code (I also used it a couple years earlier for a GUI (PointerWare) where code would await opening new windows, it wasn't really being used for concurrency there, just a nice interface of "show pop up, wait on that view to complete" which made Back buttons easy)
Here's an example where looping made for a callback that recursively called, using async/await I get to use a plain loop:
Callbacks make it difficult to send information up the call chain, as the caller fires it off without a ticket to wait on the result. libxcb is an example of a library which optimized on libx11 by having functions which return cookies which func_reply wait on, these functions could similarly be implemented as an async/await interface
I don't see why people find it so complicated to separate begin-compute & wait-on-compute
> the caller fires it off without a ticket to wait on the result
Exactly! Making a thread block waiting for a result isn't true async in my book. It doesn't matter that the result is going to come from another thread. Futures/Promises make you block a thread.
That's why async/await is about having an event loop driving a state machine so that you aren't blocking a thread, you're having a state machine wait on a result
Performance numbers don't care what's in your book
I really don't like futures/promises, I don't know where this abstraction came from.
Callbacks are where it's at. Someone, somewhere has to write callback code; they cannot be got rid of. What works for me is keeping the callback handler as short as possible, this usually means just pushing 'work' onto an async queue that is serviced by one or more threads.