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.

> 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'.

>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.

> You can write safe code using threads if you enforce that the only way threads can communicate is by sending messages to each other (via copying, not pointers).

At which point they're not really threads, they're more, well, processes.

> This is what Erlang does.

Exactly.