Erlang programming techniques

Erlang Programming Techniques

Erlang was created with the aim of "Making reliable distributed systems in the presence of software errors" as the title of Joe Armstrong's dissertation states.

The creators of Erlang has tried to solve that using a particular philosophy which makes certain programming techniques more powerful than others. This article will present the philosophy and the most powerful programming techniques.

Why this article?

This article is to a large extend a mash-up of Chapter 4 of Joe Armstrong's dissertation plus a definition of some of the key functionalities of Erlang so that the content can be easily understood by people that do not know anything about Erlang.

The intention is to provide non-Erlangers to get an idea of how Erlang affects the creation of software and what benefits that might bring about.

Fundamental Features of Erlang

Processes, Processes, Processes

Erlang provides its own processes without resorting to the underlying OS. This is done so efficiently that several millions of processes can run on the same machine. It is not just an academic show-off - the intention is to create as many processes as required to capture the truly concurrent activities of the system being created.

Pure message passing

The only way for for processes to communicate is to send messages to each other. There is no no shared state between processes which removes many of headaches normally associated with concurrent programming (todo: find reference).

Strong isolation between concurrent processes

The failure of one process will not cause other processes to fail.

Since failures are unavoidable in software Erlang has mechanisms that allows a process to detect if another process has failed and why it has failed, but the ability to detect the failure of another process does not make the process itself fail.

A failure in one process can cause other processes to fail, if and only if that behaviour is explicitly programmed.

Abstracting Out Concurrency

Although Erlang makes it easy to create concurrent programs Erlang also has the means to separate the concurrent parts of the code from the sequential parts. This makes it easier to debug and understand a program since the sequential parts are often easier to deal with than the concurrent parts which has to deal with many processes, order of message delivery, live-locks and dead-locks.

Erlang - as many other programming languages - deals with the problem by separating the programs into a generic component that can be parameterised with a number of plug-ins. The difference is that the features of Erlang provides a very powerful environment for the plug-ins to execute in, in particular error handling and dynamic code replacement makes it easy to make the separation clean and effective.

There are two ways of providing the separation.

• Write both the generic component and the plug-ins yourself.
• Use the Erlang/OTP library's behaviours as the generic components and just write the plug-ins yourself.

The Erlang/OTP library provides five behaviours that can cover most needs:

• gen_server: servers for client-server set-ups.
• gen_fsm: finite state machines.
• gen_event: event handlers, e.g., error loggers.
• supervisor: used to monitor worker processes for failures.
• application: used to bundle components together as an application.

It is also possible to create your own behaviours, but the test of time has shown that the five Erlang/OTP behaviours can deal with most practical problems without too many artificial code tricks.

Everything is a process

Erlang's view of the world is that everything is a process and that the only way for the processes to interact is by sending messages to each other.

It has never been the intention of the creators of Erlang that all software in a system should be written in Erlang (see Bjarne's technical doctor dissertation for details - todo: find referene). When interfacing with external software one can maintain Erlang's view of the world by writing an interface program which maintains the illusion that everything is a process.

Erlang comes with a rich library that provide interface programs for many things, such as TCP, UDP and files (ref: kernel). There are language libraries for writing drivers to programs in C and Java, plus guidelines for interfacing to programs in other languages (ref: linked driver).

Error Handling Philosophy

This is where Erlang has taken a radically different approach than most other technologies, but it is also this approach that greatly simplifies the work of the programmer as we shall see.

Let some other process do the error handling

No matter how much one tries to handle all possible errors in a piece of code chances are that there are still errors in the code and when one of those occur the code will fail.

Erlang is designed to utilise remote handling of errors, which gives the following benefits compared to the more traditional programming languages:

1. The failing code and the error-handling code runs in different threads of control.
2. The code which deals with the error is not weaved into the code that solves the real problem.

The different threads of control means that failures will only affect one part of the program. The separation of the error handling from the value-adding code is an example of how separation of cross-cutting concerns can be done. This paradigm is the foundation for Aspect Oriented Programming (ref: Wikipedia article).

Workers and Supervisors

Just letting some other process do the error handling is not enough to create good architectures so Erlang uses the terms workers and supervisors for the two rôles.

Worker processes are the ones providing the value-add for the customer. The Supervisor process observers the works and deal with errors occurring in the Workers.