[toast0]

At risk of being that guy, the actor model (ala Erlang) is pretty good at concurrency. If you're unfamiliar, it's basically no shared state, and communication with other actors (Erlang processes) by sending asynchronous messages to the other actor's message queue.

The code for each actor is usually pretty small and easy to reason about. However, emergent behavior of the system, and ordering between messages from multiple actors can become tricky. Also, exposure to this idea long term will warp your mind :)

[chrisseaton]

The actor model is very vulnerable to race conditions - that’s a big downside to it.

[toast0]

It depends on what is racing. If you have the same/dependent information in two (or more actors), you're going to have a coordination challenge.

So try not to do that. On the other hand, everything that happens with state within an actor is inherently non-racy, because an actor is sequential code and no other actor can mess with its state.

[acjohnson55]

The actor model is a great tool, but I think it's best looked at as a low level concurrency primitive. Most of the time, folks should be working with higher level constructs in conceptually simpler control flow paradigms like call-and-return (async/await) or streams.

[true_religion]

In Erlang, all those control flow paradigms exist in library form.

You are right about the actor model being a low-level choice, but its a choice that has to be made since the whole system revolves around allowing/disallowing shared state.

[dnautics]

It's also relatively easy to implement async/await using actor primitives.