Hacker News Reader

Comment by eikenberry | Hacker News Reader

I'm curious as to why you think that matters? Async/Await are general purpose concurrent programming abstractions.

Alright, so I do computational plasma physics simulations for a living. Given our problem sizes often reach sizes which require teraflop level of parallelism to get done before I retire (that's my scale, I'm sure you're aware of petaflop sims the fluid/engineering guys do) we do need concurrency but it's done by chopping up the domain, literally the volume of space we simulate, onto processors. Now, we could possibly do async at some level (sub node level), but we absolutely need to be syncronized globally because we are simulating real-life physics and we need to maintain causality, especially when we pass information between nodes. Say a wave front passes across one node boundary into an adjacent one, waves must move at a finite and causal manner, of course, just as if you watched a ripple on the surface of a puddle.

If we did the whole problem async (async by default as I interpret it) it would require so much bookkeeping to keep causality that would make it unreasonably difficult. For things that require causality like that, we are lucky that the default mode of computation is synchronous because it fits my problem domain perfectly.

That's why I say "not everything is web" because while async maps well to problems like a server-client type application, it doesn't map well to all problems like my problem for example. Also, as someone else said, sync is easier to reason about for problems that don't require a lot of parallelism.

At worst, you'll have to explicitly wait for all your async calls to have completed and produce results. I suppose normally the implicit wait occurs on attempt to access the result. I also suppose you have to do it anyway in a multi-processor system, and you can't be doing it on a single core.

At best, some of your CPUs would be able to run calculations for two especially fast-to-compute pieces of volume space, while some other CPUs would be busy computing a particularly gnarly block of the volume space.

The problem is that async adds a lot of overhead, and while the mythical sufficiently good compiler could remove it, in practice it is a lot of work for little benefit.

For those CPU bound jobs that do not fit in the classical openmp style scheduling, more dynamic async style scheduling might be appropriate (cilk style work stealing for example) but the async granularity is hardly ever the function boundary.

They are a real problem in desktop apps when you have to shut down the app gracefully. If you call an async function during shutdown you can't really tell when the async chain is done and you have nothing to wait for.

Just dealt with that in a .NET app that uses a 3rd party SDK that heavily uses async/wait. I had to build a whole layer of state management to just handle shutdowns. Simple threading would have been much easier.

It's different with server side code. There async/await is very nice.

That just sounds like the API wasn't designed to support async/await rather than an inherent limitation. Something like Promise.all [1] is all you need to wait for multiple promises if the API had a way to accept a promise instead of a synchronous callback.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The same problem would happen with a promise. In a desktop the user clicks "Quit". If you now have to call an async function the Quit handler will return and somewhen later the await portion of the code gets called. From the Quit handler you can't tell when the await stuff has finished so there is no clear time when you can shut down the app.

In a browser on or server side it's different.

They are, but calling a function asynchronously takes a lot longer than synchronously. For small functions the execution time could easily be increased by more than 100%. It's something that only really makes sense if the function will do (slow) I/O or a lot of computation, and the program has other things it could do in the meantime.

Making every function call asynchronous is likely to make most programs a lot slower.

Control is another reason. You relinquish control the more moving parts there are. If you ever looked into the tokio stack you realise there are a Lot Of Stuff going on.

Which doesn't mean it's bad. I'm excited about tokio and rust's async story. But I love that I get to choose.

Concurrency has overhead. On top of that, synchronous is easier to reason about.

Reply on news.ycombinator.com