When computers got more chips instead of faster speeds, the old rules of programming broke. Here is how we fix it by throwing away "locks" and using "actors."
In older programming models, developers had to manually share memory data between different tasks. To stop tasks from changing the same data at the exact same time and ruining it, they used locks. Think of a lock like a bathroom key. Only the person holding the key can go inside. While this sounds safe, it causes massive headaches as a system grows.
Two tasks are stuck forever because Task A is waiting for Task B's key, and Task B is waiting for Task A's key. Nobody moves.
Tasks are busy moving around and politely handing keys back and forth to avoid deadlocks, but they never actually get any real work done.
One poor task never gets a turn because bigger, faster tasks keep grabbing the key before it can.
In 1973, Carl Hewitt proposed a different way. He looked at physics: two physical objects cannot share the exact same space. So why should computer tasks share the same memory?
In the Actor Model, there is no shared memory. There are only "Actors."
An actor can send a message to another actor, as long as it knows the address. It drops the message in the mail and immediately goes back to work without waiting.
If an actor has too much work, it can spawn new child actors to help out. A shopping cart actor might spawn a payment actor and a shipping actor.
Instead of changing a shared variable, an actor changes its own rules for the next message. If a bank account actor gets a "$5 deposit" message, it decides that the next time it reads a message, it will act like an account with a larger balance.
To make this work in real life, frameworks break an actor down into three physical parts.
A line (queue) where incoming messages wait. The actor pulls them out one by one.
The brain of the actor. The code that decides what to do with the current message.
The actor's own data. No one else can see or touch this data. Ever.
Because the actor only processes one message at a time from its mailbox, the inside of the actor is completely safe. There is no race to change data, so you never have to write complex lock code again.
In old software, developers tried to catch every single error to stop the whole app from going down. The Actor Model does the opposite. It says: Let it crash.
Because actors do not share memory, if one actor hits a fatal error and dies, it does not poison the rest of the system.
Instead of trying to patch up broken data, a parent actor (the Supervisor) notices the child crashed and simply restarts it fresh. This is why telecom systems built on this model can run for years without ever being shut down.
Things like C# Tasks or JavaScript async/await.
Things like Erlang, Akka, or Swift Distributed Actors.