Erlang Day 3

My experience with day three of exploring Erlang through Seven Languages in Seven Weeks.

After a couple of days of having to reprogram how I approach problems coming from an OO background I’m looking forwards to tackling the areas that Erlang excels at, concurrency and reliability.


Concurrency in Erlang is build upon three basic primitives

  • ! : to send a message
  • spawn : to spawn a process
  • receive: to receive a message

Lets start with a basic example where we create a function which receives a message from another process and displays the appropriate information based on the format of the message which was passed.

If it receives a message of a finished atom it displays that the purchases have been completed and terminates.

If it receives a purchase atom it display the item and quantity which have been purchased and waits for the next purchase message.

In the code above we compile our module and use spawn to start our purchase function in a lightweight process. spawn returns a process ID which we store in a variable. We can then use this variable to send messages to our process with ! syntax. This is an asynchronous example where a message is being sent and the system which sends the message is not waiting on a reply.

Synchronous Messaging

Lets modify our functions to support synchronous messaging. The helper method purchase sends a message to the function purchase including a reference to itself so purchase can send a message back indicating it has printed the purchase.

Linking Processes for Reliability

Below we have a simple function which represents russian roulette. It accepts a number between 1 and 6 and if that number is three the process kills iteself. Any other number prints “click” and waits for the next message.

In the calling code above you can see that once the value 3 has been sent further calls to the roulette process do nothing as it is dead.

We can verify this using the following code.

% returns false

We can create our own function to monitor a process and declare when it is dead. process_flag sets a flag on the process which calls the function to convert exit signals to {‘EXIT’, From, Reason} messages, which can be received as ordinary messages. We then define how to handle the messages we receive. For a normal message we link the coroner process to any process with a PID of Process and print out that we are monitoring the process. For exit messages we print out that the process has died and why.

We can improve on this further by creating a function that not only tells us when the process has died but then restarts it for us.When we receive a new message we spawn a roulette process and link it to our doctor process so the doctor process will get notified if it dies. We register the roulette processes id with the revolver atom. This allows us to send messages to the roulette process using revolver ! message without needing the PID. The exit handling has been enhanced to send a message to itself telling it to spawn a new game.

This is just a basic example to demonstrate how Erlang creates robust concurrent systems by providing libraries that make it easy to monitor processes, determine when they have crashed and restart them. As mentioned in previous blogs Erlang encourages you to ‘Let it crash’ rather than putting in lots of error handling.

Self Study

Open Telecom Platform (OTP) is a powerful package with much of what you’ll need to build a distributed, concurrent service.


An OTP service that will restart a process if it dies

Documentation for building a simple OTP server


  • Monitor the translate_service and restart it should it die.
  • Make the Doctor process restart itself if it should die.
  • Make a monitor for the Doctor monitor. If either monitor dies, restart it.

The following bonus questions will take a little bit of research to complete:

  • Create a basic OTP server that logs messages to a file.
  • Make the translate_service work across a network.

Check out my code at github