The Actor model was first created by Carl Hewitt and others [1] before being further developed by William Clinger during his graduate mathematics work [2]. Originally developed as an approach to modeling various problems in the then-nascent field of artificial intelligence, we can thank Gul Agha for helping the Actor model grow into the model of concurrent (and sometimes distributed) computation we know today [3]. Based around the simple notion that autonomous agents, called Actors, are themselves a primitive of concurrent computation, the Actor model has inspired countless advances in programming language research. Fittingly, these advances gave rise to a whole host of concrete implementations in various programming languages which have influenced systems research even more than they’ve impacted industry.

Actors communicate by message passing between actor mailboxes and may not share any state. All actors execute at the same time and may perform a limited set of actions. These core ideas of the Actor model revolve around three rules, called the Actor axioms, whose simplicity betrays the profundity of their consequences. Since actors communicate solely by message passing, the axioms dictate that a given actor may take the following actions in response to receiving a message.

In support of the axioms, we may naively define \(A\) as the set of all actors such that \(A = \{a|Actor(a)\}\) and \(M\) as the set of all messages such that \(M = \{m|Message(m)\}\). Ergo, two actors communicate with one another by means of a sequence of messages indicated generally by the notation

Since this model is both very simple and very general, it may surprise some that the Actor model remains extraordinarily influential to this day. Consider, the popularity of programming platforms such as Erlang/OTP and Elixir, Akka on the Java Virtual Machine (JVM), and Akka.NET on the Common Language Runtime (CLR). Moreover, look to the rapid proliferation of Actor-inspired Rust concurrency frameworks such as Actix, spaad/xtra, and Riker. Despite the plethora of Actor model implementations, the axioms unite them all in a single, unifying set of theoretical underpinnings.

What might not be immediately apparent, however, is that the simplicity and generality of the axioms give rise to some interesting considerations. For example, how can one actor, \(a_0\) send messages to another actor, \(a_1\), but not a third actor, \(a_2\)? Really, how does \(a_0\) know that \(a_1\) even exists? This brings us to the topic of actor names, sometimes called addresses, which are sort of like handles in traditional programming paradigms. In order for \(a_0\) to communicate with \(a_1\), it must first know its name. Therefore, knowing an actor’s name is a very powerful thing, very much on par with an access capability. This might not seem like a profound consequence, but it will come up time and again. Some frameworks even have a special type, usually called something like ActorRef, which represents an actor’s name. Without it, you cannot send messages to that actor.