3 ms·

> Anyways; good for Ruby! Async/await just seems very faddish to me: it didn't solve any of the hard multithreading/multiprocessing problems, and introduced a b

> Anyways; good for Ruby! Async/await just seems very faddish to me: it didn't solve any of the hard multithreading/multiprocessing problems, and introduced a bunch of other issues. My guess is that it was interesting type theory that bled over into Real Life. I think what happened what that JavaScript absolutely necessitated the addition of async/await to avoid callback hell (due to its single-threaded mandate)... just to create a new kind of hell all of its own. But before the long-term consequences within large code bases could be observed, the cool kids like C# & friends jumped on the bandwagon believing that "more syntax equals more better code".

incrudible 2y ago
Javascript necessitates async because of its focus on UI. You just can not have good UI while blocking on the main (or UI) thread, you will inevitably have something like async and callbacks, so you might as well embrace it. Whether that is a good tradeoff for a server is a different question.
- DarkNova6 2y ago
  What you need is concurrency. And async/await is just one form of concurrency. I don’t see why you would need threads to create a stackful coroutine implementation. However, what you would indeed need is a much more heavy runtime.
rpeden 2y ago
Async and await appeared in C# well before they were added to JavaScript, so I'm not sure the reasoning of your timeline makes sense.
- DarkNova6 2y ago
  You are right. I already saw it on other replies. Thanks for pointing it out here as well.
  - rpeden 2y ago
    Hopefully I didn't seem too pedantic. I don't think C# having it first necessarily diminishes your point about the use of async and await in JS. Async and await were nice additions in C# to make working with tasks more convenient, but there were other ways to manage async tasks without ending up with a tower of callbacks. The situation was messier in JS.
masklinn 2y ago
> I think what happened what that JavaScript absolutely necessitated the addition of async/await to avoid callback hell (due to its single-threaded mandate)... just to create a new kind of hell all of its own. It’s not really “a new kind of hell”, there’s a logical progression from callbacks to reified callback (promises) to coroutines, and each step makes concurrency more manageable so you do more of it until you hit a new wall. And client-side JS probably can’t ever be preemptive, so not only would a thread model require adding a ton of tooling at once it would still behave quite strangely.
- anonymoushn 2y ago
  The alternative isn't preemptive threads, it's coroutines with subroutines that can yield.
  - masklinn 2y ago
    Yes, cooperative threading, the worst of all worlds.
    - anonymoushn 2y ago
      imo we should reify more capabilities in the type system. you shouldn't be able to call Math.random without all of your transitive callers declaring at the call site that you plan to do that.

incrudible 2y ago

Javascript necessitates async because of its focus on UI. You just can not have good UI while blocking on the main (or UI) thread, you will inevitably have something like async and callbacks, so you might as well embrace it. Whether that is a good tradeoff for a server is a different question.

DarkNova6 2y ago
What you need is concurrency. And async/await is just one form of concurrency. I don’t see why you would need threads to create a stackful coroutine implementation. However, what you would indeed need is a much more heavy runtime.

rpeden 2y ago

Async and await appeared in C# well before they were added to JavaScript, so I'm not sure the reasoning of your timeline makes sense.

DarkNova6 2y ago
You are right. I already saw it on other replies. Thanks for pointing it out here as well.
- rpeden 2y ago
  Hopefully I didn't seem too pedantic. I don't think C# having it first necessarily diminishes your point about the use of async and await in JS. Async and await were nice additions in C# to make working with tasks more convenient, but there were other ways to manage async tasks without ending up with a tower of callbacks. The situation was messier in JS.

masklinn 2y ago

> I think what happened what that JavaScript absolutely necessitated the addition of async/await to avoid callback hell (due to its single-threaded mandate)... just to create a new kind of hell all of its own. It’s not really “a new kind of hell”, there’s a logical progression from callbacks to reified callback (promises) to coroutines, and each step makes concurrency more manageable so you do more of it until you hit a new wall. And client-side JS probably can’t ever be preemptive, so not only would a thread model require adding a ton of tooling at once it would still behave quite strangely.

anonymoushn 2y ago
The alternative isn't preemptive threads, it's coroutines with subroutines that can yield.
- masklinn 2y ago
  Yes, cooperative threading, the worst of all worlds.
  - anonymoushn 2y ago
    imo we should reify more capabilities in the type system. you shouldn't be able to call Math.random without all of your transitive callers declaring at the call site that you plan to do that.