What is Erlang?


Feb 2013

You will touch Erlang at some point, if you follow the development of distributed systems. Erlang is a remedy to the pains of a monolithic application. And great programmers such as Adam Wiggins or Jose Valim name Erlang in the context of scalable systems e.g. in this article or here. So, I was curious enough to attend a great, small conference on Erlang: Munich Erlang Factory Lite 2013

As someone who is new to Erlang, a first question must be asked: What is Erlang? Let’s look at different aspects.

How does Erlang code look like?

  • At first, Erlang code does not look much different from Ruby, JavaScript or CoffeeScript: You’ll see traces of a dynamic type system and Erlang allows to dynamically run code with some kind of console, the Erlang Emulator (“ERL”).

  • Looking more at the code, you’ll see that lines of code sometimes end with a “dot”. This triggers code execution. As a beginner, it’s the moment when you see error messages and interpretation of error messages is rather difficult. To me, Erlang errors are cryptic, and apparently line numbers in errors were a late innovation.

  • Further, the code you’ll see may contain tuples and atoms, some of the main data types in Erlang. Nota bene, the concept of String is not a data type in Erlang, but rather an Array of characters as in e.g. C. Some people say this makes string operations more difficult than in other languages. Other people say, it’s less error prone too. To a beginner, it’s hard to judge.

Erlang modules and libraries

Once programming, you will quickly discover an important Erlang concept: Modules. Modules wrap functions and behavior of code. Additionally, modules can be distributed within libraries, and as in any other programming language, libraries make a programmer’s life fun.

The magic command to import libraries into your Erlang project is “rebar”. Rebar also allows to easily create a new Erlang project. And, rebar is from Basho.

Why Erlang?

So far, so good. Erlang programming is about functions and values, and that sounds like no big deal to some. However, the main aspects of Erlang are reflecting on errors when needed, and reliably running concurrent processes. It’s here where the Erlang fun part starts, and other languages just suck (for the skeptics, maybe you can read the books suggested here).

  • In Erlang, there seems to be the idea of “let it crash”. In a monolithic application, this usually means the death of an application. In a Unix system, this may mean to kill a process. In Erlang, you get a supervisor that may take care of this, when a process is idling or conflicting with another process. The supervisor may decide to retry, continue, or check later. This is new to me, but I haven’t come across this mentality in any other pogramming language so far.

  • Having better ways to deal with exceptions, you’ll also get better ways to deal with concurrency. It’s rather new to me, but to understand why this helps, think of a monolithic application that triggers delayed jobs. If you run you run multiple applications in your server cluster, and have eventually multiple delayed jobs, from my experience, you can get race conditions and other problems, that are really hard to debug. Erlang to the rescue. With Erlang, you’ll get some ways to have processes check what another process is doing. The mechanisms that you’ll hear people talk about are monitoring or linking processes, resulting into process robustness. The code of RabbitMQ must show clever ways to deal with message concurrency.


So, my main conclusions:

Leave me feedback

comments powered by Disqus