Hacker News new | ask | show | jobs
by brabel 2213 days ago
If you think async/await is the holy grail of networking, you're up for a surprise in the next few years.

The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...

This seems to me to obsolete async/await, quite honestly.

3 comments

Don't fall into the trap of thinking that just because you've found a blog post that could enumerate the downsides of something that the alternatives don't have the same trade-offs.

I've responded to that ancient blog post many times on HN by now. Since you must think that blog post is pretty good criticism of async/await, here's a little challenge for you: which language do you think doesn't have an equivalent of the "red vs blue" problem? :)

> Don't fall into the trap of thinking that just because you've found a blog post that could enumerate the downsides of something that the alternatives don't have the same trade-offs.

I've been using async/await for a long time and I thought it was great, but since I started using JDK15 virtual Threads, I feel like it's way superior in every way. If you have some trade offs you would like to mention, please do.

> which language do you think doesn't have an equivalent of the "red vs blue" problem?

Any language that distinguishes between async and non-async functions will have this problem. I believe one language that works around that is Erlang, as Erlang seems to do everything async (but it's not visible to users, but I am not sure). The proposed Java virtual Threads solve that problem as well. You should open your mind to new ways of doing things, this is by no way a solved problem as you so strongly seem to believe.

A link to one of your responses would be spiffy.
I skimmed the Loom article and I don't see how it obsoletes async/await. It seems primarily focused on performance.

But that's not the problem that async/await solves for me. I like JS concurrency because shared-memory concurrency is very hard to program correctly. By using a single-threaded event loop with async/await, I know exactly when it's possible for the contents of memory to change out from under me: only when I `await`. This makes it much easier for me to reason about the correctness of my application.

Given that Node.js makes it easy to spin up processes on multiple cores (e.g., with a library like worker-farm), I get full CPU utilization without the safety and liveness problems that shared-memory threads have. This is very nice.

> If you think async/await is the holy grail of networking,

They wrote that it's better, not perfect.