Hacker News Reader

Comment by groundzeros2015 | Hacker News Reader

groundzeros2015·

Such as? The entire premise of async is that callbacks were a mistake because they broke sequential reasoning and control.

Every explanation of the feature starts with managing callback hell.

View on HN

Beware, they are different concepts.

Threads offer concurrent execution, async (futures) offer concurrent waiting. Loosely speaking, threads make sense for CPU bound problems, while async makes sense for IO bound problems.

Why? You write the same code with async await but with a keyword at the beginning of every function.

Only if you ever deal with one future at a time. But async allows things like awaiting one of N events in a very natural way. Those patterns are much less readable when done with threads.

Because if you go down the callstack eventually you won't get the await keyword anymore; you'll get the actual 'waiters' and 'wakers' which define your scheduling

Yeah. The OS handles scheduling and preemption so it’s done for you rather than a call in the stack.

The entire premise of callbacks is that threads were a mistake because they broke sequential reasoning and control.

JK, obviously callbacks became prominent as a result of folks looking for creative solutions to the C10K[0] problem, but threads have a long history of haters[1][2][3].

[0] https://en.wikipedia.org/wiki/C10k_problem

[1] https://brendaneich.com/2007/02/threads-suck/

[2] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf

[3] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...

Async/await implementations usually also come with a runtime to handle the work scheduling as well as manage thread context. You can say that you can do that with just threads and callbacks but that's also essentially implementing async/await.

The callbacks should be just hidden from programmer, that's what async/await are for.

Reply on news.ycombinator.com