Erlang's actor model

Erlang is a language and platform designed by Ericsson, whose scope is supporting distributed, real-time and fault-tolerant computation. It has become famous in the programming world probably as the platform on which CouchDB was developed.
Erlang has some peculiarities that make it different from the usual imperative, mainstream languages:

• it is a dynamic, functional language; even more than Clojure in some aspects.
• As a result, it forces single assignments and immutability: you cannot change existing variables, only create new ones. All state is kept on the stack in the form of function calls and their parameters.
• Concurrency and message passing is supported at the language level, as actors (called processes in Erlang).

Actor model

Every process of the Erlang virtual machine is an actor:

• actors execute independently and communicate only with one-way messages.
• Actors can create other actors.
• When an actor finished its computation, it disappears.

Like all paradigms, the actor model is defined by what it takes away from the programmer:

• no shared memory between processes.
• No remote procedure call: only messages sent via asynchronous invocations.
• As a result, no return values since messages go in one direction (although of course this can be simulated with another, separate message.)

Note that Erlang processes run inside one or more virtual machines on one or more nodes of a network, so they do not map to OS processes.

An echo server

Without taking too much consideration for Erlang's syntax, let's see it in action. An echo server is a process sending you back the messages you send to it.
This first example will serve to use both to learn a bit of Erlang's look&feel, and to introduce the primitives for creating actors.

-module(echo).
-export([start/0]).

loop() -> receive
    {Sender, Num} ->
        Sender ! Num,
        loop()
    end.

start() -> spawn(fun loop/0).

This is contained in a echo.erl file, where we define a module named echo. All identifiers starting with lowercase are atoms, while variables start with an uppercase letter. This means Num is a variable, while num would be a constant symbol that cannot be assigned but only passed around (like Ruby symbols or Clojure keywords).

We define two functions loop() and start(), but export only start/0 (the start version with 0 arguments); the complete signature of a function always comprehends its arity (the number of arguments), so start() and start(Variable) would be two different functions.

In loop/0, we use the receive primitive to receive one new message from the queue for this process. We define a pattern for the message - we only accept tuples containing two variables.

After receival, we send back a message to the process identified by the first half of the tuple, containing the number in its second half. We then restart listening by tail recurring on loop() until a new message is delivered.

start/0 is instead a primitive that has to be called from the originating process. It would call spawn/1 to create another process which will execute the loop function; it will then return the control to the calling process.

Here's how to use this echo server. The shell will be our originating process, while the process for echo will be created:

[giorgio@Desmond:~]$ erl
Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]

Eshell V5.8.3  (abort with ^G)

We compile the echo.erl source file:

1> c(echo).
{ok,echo}

We call start() from this process. Another process is spawned, but spawn() returns its process id. Since it is the last statement of start(), also start() returns the same value, which we can save in a variable. The value of the id is shown, as all other return values of local function calls:

2> Pid = echo:start().
<0.39.0>

Now we send a message to Pid, a tuple containing two values. A tuple is a simple data structure containing a fixed number of values (it is the generalization of a pair or of a triplet):

3> Pid ! {self(), 42}.
{<0.32.0>,42}

Now the other process will handle the message and send one back to us. When we want to receive it, we can invoke receive with an identity handler, just displaying what we have got back:

4> receive Value -> Value end.
42

Let's complicate this a bit

Let's try to encapsulate some state into our server. We code a new module called var, which will represent a number we can add to or display.

-module(var).
-export([init/0, add/1, get/0]).

init() ->
    Pid = spawn(fun() -> loop(0) end),
    register(variable, Pid).            % we keep track of the process id

loop(N) ->
    receive
        {add, X} -> loop(N+X);          % we accept more than one type of message: the first has the atom add as the first element for identification
        {Parent, get} ->                % in case of get, before restarting the loop we send a message to Parent with the value
            Parent ! N,
            loop(N)
    end.

add(X) ->                       % these primitives can be called from the parent process, like init()
    variable ! {add, X}.

get() ->
    variable ! {self(), get},
    receive Result -> Result end.

The server has the same structure, but it accepts more than one type of message, distinguishing between them via pattern matching. Moreover, it performs some operations like Parent ! N before tail recurring.

The add/1 and get/0 primitives are meant to be called from the client process, and encapsulate the messages to send to the server process, along with the blocking for receiving results. To manage multiple created processes, we would have to save pids in a list.

Conclusion

As you know, different approaches to concurrency such as functional programming and the Actor model are likely to play a role in the near future due to the rise of parallel and distributed computing. To delve into this new world, I'm currently test-driving a distributed tuple space (like JavaSpaces) in Erlang: the mix of a functional language and the actor model is a big change for an OO developer to deal with.