Hacker News new | ask | show | jobs
by mike_hearn 820 days ago
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.
2 comments
mrkeen 820 days ago
> 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'.

link
logicchains 820 days ago
>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.

link