A shallow dive into Erlang

Concurrency is increasingly important for a simple reason: Moore's Law is reaching its limits. That is, the number of transistors on a processor can no longer double every two years, due to fundamental laws of physics and practicalities of chip fabrication.

As such, instead of trying to make processors faster, hardware manufacturers are putting more processors on a chip and more cores in a processor. As with computing in general, when vertical scaling become too difficult and expensive, horizontal scaling is the way forward.

In fact, concurrency is so important to the future of programming that Guy Steele, creator of Scheme, declared that lists and accumulators are passé and that we need different data structures and algorithms going forward.

It's clear that concurrent systems are the future, and building concurrent systems requires concurrent languages–that is, languages designed with a good concurrency model from the start, not ones had it shoe-horned in later¹.

To learn about concurrent languages, I started with Erlang, a language originally developed by telecom company Ericsson in the 1980's for programming network switches. As such, concurrency, fault tolerance, and avoidance of shared state were key goals from the start. Over the years, the language has evolved to become a general-purpose programming language, no longer restricted to the telecom industry².

The language's concurrency model is its most distinguishing feature. In Erlang, calculations take place in light-weight³ processes managed by the VM. Processes do not share state–when they communicate, they send all necessary data via messages. Thus, when a process fails, it can be quickly restarted without affecting other processes or corrupting global state.

I've been exploring a bit of Erlang through Fred Hebert's Learn You Some Erlang⁴, an approachable introduction to the language. In many ways, Erlang is like Lisp–old and crufty, with a rabidly loyal community that trumpets its strengths and excuses its weaknesses. As such the barrier of entry for newcomers is unnecessarily high, and a Hebert's work lowers that barrier significantly.

I'll be exploring Erlang in the weeks to come. There's also Elixir, a new language for the Erlang VM that has nicer syntax, which I may also take a look at.