top | item 42134866

(no title)

will_crusher | 1 year ago

[flagged]

discuss

order

flohofwoe|1 year ago

Coroutines via user-mode stack-switching worked just fine for decades. Async/await is really only needed on limited runtime environments like Javascript or WASM where stack switching isn't an option (and at the cost that the compiler needs to turn sequential code into a switch-case state machine under the hood, which then introduces all sorts of problems, from 'function coloring' to requiring special support in debuggers).

gpderetta|1 year ago

Everything above machine code is about hiding complexity. That per se is not an issue. Programming in CPS form is madness, async/await is only slightly better than that.

tightbookkeeper|1 year ago

> non-blocking

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.

will_crusher|1 year ago

while we’re waiting for the OS to ‘save us’ from async/await, let’s not ignore the fact that writing code that doesn’t hang, crash, or block the main thread is a skill for a reason.