Hacker News Reader

Comment by dodobirdlord | Hacker News Reader

I think in a lot of cases the async programming model is easier to work with than the thread programming model. In a sense it’s declarative vs procedural programming over again. With threads you have to identify parallelism opportunities at write time, and if you plan poorly you can end up with low core efficiency. With async programming you break your execution up into a graph of inputs and outputs and let your async scheduler dynamically bin-pack everything, paying an overhead for consistently high core efficiency without having to think about it or change your code very much.

View on HN

It's also useful as documentation even in single-tasked programs, since async ends up as a "good-enough" IO monad.

Then again, few programs are actually single-tasked in practice, and libraries often end up taking advantage of those async primitives for doing stuff like connection pooling even if your application code doesn't see it.

I always thought this, but people don't seem to find the convenience of async as a strong selling point over threads. There isn't a fundamental reason, but doing something like:

  thing1_promise = get_thing(1)
  thing2_promise = get_thing(2)

  thing1 = thing1_promise.await
  thing2 = thing1_promise.await

is almost always more difficult to do with threads. Sure, some threading APIs support joining nicely but it tends to be more awkward. Especially if you want to do something like handle the first request to finish first.

Also the startup cost of threads affects how you write code. Does your library spawn a new thread for every HTTP request? Probably not, it is expensive and the server may be on the same host. So you end up with less consistent async support. Since async programming is a lot cheaper you tend to see better support which adds up.

That's a very intriguing metaphor.. and reminds me of the optimization manually vs using `gcc -O2` .. I am wondering if the "pre-mature optimization is the root of evil" quote applies here and we should all just use async first and only go for threaded/multi-processing programming if there seems to be a performance issue for the business application.

It’s probably very painful to try to convert a piece of async software to use a threaded model (though I’m just guessing, having never had to attempt this), so I’d say it’s more a matter of thinking up front about whether you need to control threads directly. But to your main point, I agree. I suspect the vast majority of software has no need for thread-model parallelism, and languages have only historically presented that parallelism model because it’s the model that the OS exposes to userland, even though the OS scheduler is async-style scheduling the machine threads themselves!

You might not even need to do that, most async runtimes support some kind of middle ground where you take explicit control over which tasks are scheduled to which threads.

Reply on news.ycombinator.com