Hacker News Reader

Comment by DarkNova6 | Hacker News Reader

> 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".

View on HN

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.

You are right. I already saw it on other replies. Thanks for pointing it out here as well.

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.

> 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.

The alternative isn't preemptive threads, it's coroutines with subroutines that can yield.

Yes, cooperative threading, the worst of all worlds.

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.

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.

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.

Reply on news.ycombinator.com