Why choose async/await over threads?

Re:Why choose async/await over threads? by mike_hearn on Monday March 25, 2024 @06:29AM (#39814509)

No, you can get races and deadlocks in a pure actor system as well. It's actually easier in my experience to end up with problems in actors. I tried writing an app in that style once and had to back off that design and introduce some traditional shared memory multi-threading on some codepaths.

There are no shortcuts, no silver bullets when it comes to concurrency. Programmers have to learn about multi-threading and the ways it can go wrong because it's a fundamental thing, not a mere feature you can design your way out of.

[ Parent | on HN ]

Re:Why choose async/await over threads? by mrkeen on Monday March 25, 2024 @08:01AM (#39815214)

> There are no shortcuts, no silver bullets when it comes to concurrency.

But you can identify the opposite of the silver bullet, which is shared mutable state, and then hurry away from it as quickly as possibly.

Rust defaulted to avoiding sharing and Haskell defaulted to avoiding mutability.

For application code, I've yet to see a better concurrency story than 'use pure functions where possible, or use STM when you absolutely need shared mutation'.

[ Parent | on HN ]

Re:Why choose async/await over threads? by logicchains on Monday March 25, 2024 @06:44AM (#39814598)

>No, you can get races and deadlocks in a pure actor system as well.

You can't get data races, which is what Rust prevents. Rust's async doesn't prevent deadlocks or other kinds of races.

[ Parent | on HN ]