What is an actor model in the context of a programming language?

Question

I saw him mentioned in several places in contexts such as actor model Erlang, actors Groovy, actor model Scala, etc. What does it mean?

Answer 1

I think Wikipedia sums it up:

The Actor model adopts the philosophy that everything is an actor. This is similar to the fact that all this is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is usually executed sequentially, while the Actor model is essentially parallel. [snip] The Actor model is message passing semantics.

Answer 2

Some time ago, I wrote this blog post explaining the basic concepts of a model and building a basic implementation using JavaScript. From the post:

In the Actor model, the actor is the foundation on which you build the structure of your application, it has an internal state that is invisible to the outside world, and interacts with other participants through asynchronous messages.

If that sounds a lot like Object Oriented Programming (OOP) for you, you're right. The Actor model can be considered as OOP with special message processing: they are transmitted asynchronously and executed synchronously by the receiver.

Each actor is identified with a unique address where you send him messages. When a message is processed, it is mapped to the current behavior of the actor; which is nothing more than a function that defines the actions to be taken in response to a message. In response to a message, an actor can:

• Create more members.
• Send messages to other participants.
• Assign an internal state to process the next message.

Answer 3

The main idea of the actor model is to manage actors as primitives for parallel computing. An actor can send messages to other actors, receive and respond to messages, and spawn new actors.

The key idea here is to communicate through messages, rather than sharing memory between different threads.

It is important to add that the subjects are asynchronous and parallel, but they do not guarantee the order of the messages or the time limit as to when the message can be affected (therefore, atomic transactions cannot be divided into subjects).

Using the Actor model is suitable in two main cases:

• When you can decompose your decision into many independent tasks.
• When you can decompose your decision into a set of tasks related to a clear workflow.

Illustration: