4 ms·

Threads are neither better or worse than async+callbacks. They are different. There are problems which map nicely to threads and there are problems which are mu

Threads are neither better or worse than async+callbacks. They are different. There are problems which map nicely to threads and there are problems which are much nicer to express with async.

groundzeros2015 5mo ago
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.
- codedokode 5mo ago
  The callbacks should be just hidden from programmer, that's what async/await are for.
- repelsteeltje 5mo ago
  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.
  - groundzeros2015 5mo ago
    Why? You write the same code with async await but with a keyword at the beginning of every function.
    - f_devd 5mo ago
      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
      - groundzeros2015 5mo ago
        Yeah. The OS handles scheduling and preemption so it’s done for you rather than a call in the stack.
    - pkolaczk 5mo ago
      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.
- jazzypants 5mo ago
  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 https://en.wikipedia.org/wiki/C10k_problem [1] https://brendaneich.com/2007/02/threads-suck/ https://brendaneich.com/2007/02/threads-suck/ [2] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf [3] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...
- jayd16 5mo ago
  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.

Threads are neither better or worse than async+callbacks. They are different. There are problems which map nicely to threads and there are problems which are much nicer to express with async.

groundzeros2015 5mo ago

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.

codedokode 5mo ago
The callbacks should be just hidden from programmer, that's what async/await are for.
repelsteeltje 5mo ago
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.
- groundzeros2015 5mo ago
  Why? You write the same code with async await but with a keyword at the beginning of every function.
  - f_devd 5mo ago
    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
    - groundzeros2015 5mo ago
      Yeah. The OS handles scheduling and preemption so it’s done for you rather than a call in the stack.
  - pkolaczk 5mo ago
    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.
jazzypants 5mo ago
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 https://en.wikipedia.org/wiki/C10k_problem [1] https://brendaneich.com/2007/02/threads-suck/ https://brendaneich.com/2007/02/threads-suck/ [2] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf [3] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...
jayd16 5mo ago
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.