In this post, we’re going to look at a piece of technology that was banned by the company that created it. It was kept alive by a small team of enthusiasts. Then, almost thirty years after its first development, it became the core technology underpinning one of the most important and lucrative startups of the 2010s.

Today, it plays a key role in services that are used by billions across the world.

We’re talking about the Erlang programming language.

Why is Erlang interesting? Well, one of the themes of this newsletter is that old technology can be incredibly valuable and useful. Erlang was often seen as an esoteric curiosity, until a small group of entrepreneurial engineers used it to create a start-up that they sold for billions of dollars.

Erlang’s history also has a number of lessons. The spread of general purpose hardware and software into specialist areas like telecoms. The power of individuals and small teams using the right software tools. The resilience of open source software. And more.

This is our first post on a programming language. Except it isn’t entirely about software, it’s about how software can make the most of the hardware resources available and the links between the hardware of computing and that of telephony.

So, what is Erlang, how did it come into being, and why has it had a renaissance recently?

We’re going to start at the place where Erlang was born. In Stockholm in Sweden.

If you’re old enough, you may remember Ericsson mobile phone handsets which were a popular choice in the pre-smartphone era. Today, Ericsson’s business is focused on telecommunications equipment.

Ericsson was founded by Lars Magnus Ericsson in Stockholm, Sweden in 1876. In 1878, it started making and selling telephones and switchboards. Over the following decades, Ericsson had mixed fortunes and, after a period of financial difficulties, it was rescued by banks controlled by the Wallenberg family. By the 1960s, the Wallenbergs had full control of Ericsson.

We’ve previously met Ericsson in recounting the story of the first RISC computer, the IBM 801. IBM wanted to to enter the telecoms equipment market and considered joining forces with Ericsson, with the development of a new computer at the center of a possible joint venture. After a series of secretive meetings at London’s Claridges Hotel, that came to nothing.

But telephony in general, and Ericsson in particular, needed computing.

In 1980, a small group of Ericsson engineers – Bjarne Däcker, Mike Williams, Göran Båge and Seved Torsten-dahl – proposed creating a Computer Science Laboratory (CSL) within the company. Their objectives were to create software technology for future telecoms systems and to help introduce that technology into existing Ericsson systems.

Their hardware mixed industry standard computers with specialised telecoms hardware, with a DEC VAX 11/750 minicomputer linked to an Ericsson telephone exchange.

Earlier work to program telecom systems at Ericsson had used a range of languages including PL163, CHILL and modified versions of the Pascal programming language.

Now the team started to look at a range of existing programming languages, each of which brought its own approach. These languages included then mainstream languages like Ada and lesser known ones such as Concurrent Euclid, PFL, LPL, OPS4, Frames and CLU.

As the team’s work progressed, it became clear that none of these individual languages by itself would meet all the team’s requirements.

In 1985, the group was joined by Joe Armstrong and Robert Virding.

Then in 1988, the Lab moved from Ericsson to Ellemtel, a joint venture between Ericsson and the Swedish national telecoms provider Televerket.

The focus now was on building software to program AXE, Ericsson’s telephone exchange, which was programmed in a language called PLEX. The motivation was to “to make something like PLEX, to run on ordinary hardware, only better.”

Carrying forward some properties of PLEX was considered essential. In particular, according to Armstrong:

Firstly, it should be possible to change code “on the fly;” in other words, code change operations should be possible without stopping the system.

Software systems need to be updated and maintained with new code replacing old. A telephone system can’t be taken down completely whilst a set of code updates are introduced. Customers would not be happy if they can’t make their calls!

The language also needed to support many simultaneous activities, as calls were routed between users, and it had to be able to do this efficiently. Again, according to Armstrong, the language had to take replicate this property of telecoms switching systems:

A switching system is made from a number of individual switches. Individual switches typically handle tens to hundreds of thousands of simultaneous calls. The switching system must be capable of handling millions of calls and must tolerate the failure of individual switches, providing uninterrupted services to the user.

To this was added the conclusions of the earlier work to test a variety of languages. In particular:

• Small languages were thought desirable.

• Functional programming was liked.

• Logic programming was best in terms of elegance.

• Concurrency was viewed as essential for this type of problem.

Armstrong experimented with Smalltalk, but his attention was drawn to Prolog. Experimenting with building a system in Prolog soon led to something distinct:

What started as an experiment in “adding concurrency to Prolog” became more of a language in its own right and this language acquired a name “Erlang,” which was probably coined by Bjarne Dacker. What did the name Erlang mean? Some said it meant “Ericsson Language,” while others claimed it was named after Agner Krarup Erlang (1878 – 1929), while we deliberately encouraged this ambiguity.

Naming Erlang after Agner Krarup Erlang the Danish Mathematician who worked in the fields of traffic engineering and queuing theory, was surely appropriate for a language used to route telephone calls!

Robert Virding was now working with Armstrong on Erlang and by the end of 1988 most of the key ideas in Erlang had been implemented.

So what made Erlang different, and how did it support the Ericsson team’s requirements?

At the centre of Erlang was the idea of thousands and thousands of ‘processes’. These are separate pieces of code that run largely independently of each other. Each process communicates with other processes using ‘messages’, small amounts of data that are sent and received by each process.

Each process has a ‘mailbox’ which it can check from time to time and take action depending on the contents.

Furthermor