A Brief History of Erlang and Elixir

As a web developer, you run into issues you probably didn’t know had been resolved twenty years ago. Telecommunications and the web worked in different ways for years: until recently, the former was all about latency, concurrency, and long-running connections, while the latter, with HTTP, was just about “hits” on ephemeral connections. But the web evolved rapidly, and the things that were important in telecommunications became important for the web, too.

Evolution of the web

When it began, the web (the World Wide Web) was quite simple. Servers were delivering static files, mostly HTML pages, without any kind of intelligence or personalization behind it. Everybody was accessing the same information if they were using the same URL.

In the 1990s, the web started to become dynamic. First, with some common gateway interface (CGI) scripts, but then mostly by the adoption of a newcomer, hypertext preprocessor (PHP). Those ways to propose web pages allowed developers to provide custom pages, according to the parameters of the request, or the user requesting it. The use of databases enabled pages to be rendered dynamically, instead of generating a lot of separate pages for collection of results. This was the real start of collaborative web apps, from which we saw the emergence of the bulletin board system (BBS) and forums, or the first search engines, for example.

But at that point, all the intelligence was on the server side; in the 2000s, the arrival of Flash and JavaScript changed everything. Now, developers could make browsers download some of the intelligence and ask them to execute it. Of course, this wasn’t pain-free: with Flash (with ActionScript) and JavaScript having almost total access to the client machine, your files could easily be damaged. (This was the time before sandboxing had become a thing, of course.) Nevertheless, installing these computations on the client machine allowed interesting things to occur, such as the browser to sort data or render some parts of the page at least, giving the server a chance to catch its breath during those times when everybody was starting to get the Internet installed at home.

And then, everybody had access to the Internet, on smartphones, tablets, in the car… In the 2010s, servers started to get overloaded. We began demanding more and more, at faster and faster speeds, for multiple users at a time… The systems became more complex than ever— everyone began expecting real-time computing, but polling came at a cost, so we made alternatives, such as WebSockets and Server-Sent Events. Most of the websites are written using PHP, Ruby, Python, Java or Node.js, the first three being scripting languages, which means that they’re not compiled, and therefore obviously less efficient than .NET or Java web apps in most cases. However, a scripting language usually doesn’t need a big server like those apps do and doesn’t need to warm up a Virtual Machine (VM) first. Last but not least, concurrency in those scripting languages is devoted to the web server, not the language itself. You’ll run into race conditions or bottlenecks if you don’t think “concurrent” when you’re coding.

Hello Mike, hello Joe…

Concurrency. In the 1980s, a telecoms company examined this issue and, after some tests, decided to develop its own language: Erlang. In those days, there weren’t as many languages as there are now. C was the predominant one but, despite its versatility, three developers at Ericsson—Joe Armstrong, Mike Williams, and Robert Virding—realized they could be more productive using a higher-level language. They experimented with existing ones, but weren’t satisfied, so in 1987 they started to write Erlang, presenting it three years later.

The language was mainly used by telecommunications companies for years, the main focuses of it being distribution, fault tolerance, and high availability with hot-swapping code. This was made to address all common problems in telecommunications, where you’re not in a position to cut all the lines when you update your codebase, and you can’t let systems go down, even if no humans are there to resolve the issue. This makes a well-written program in Erlang practically a self-healing one. In 1998, Ericsson decided to make it open source, with the company still supporting it with a dedicated team. Since then, the language has been used in very specific projects, such as the well-known message broker RabbitMQ, the XMPP server ejabberd, and Apache CouchDB, which is a reliable distributed document-oriented database. Some businesses use Erlang for telecommunications products, such as WhatsApp, and Riot Games, the editor of League of Legends.

From Ruby to Elixir

In 2010, while José Valim was working on improving the Ruby on Rails framework performance on multiple core systems, he found himself getting increasingly frustrated by the experience. He realized that Ruby was not well designed enough to solve concurrency problems, so started to research how other technologies were doing it. He discovered Erlang, and his interest in its VM was piqued enough that he started to write another language, on top of Erlang. This language is Elixir, a dynamic, functional language that makes use of everything the Erlang VM provides and enables higher extensibility with macros and polymorphism, while maintaining compatibility with Erlang’s ecosystem. Besides those advantages, Elixir has a syntax that is “Ruby-ish” and far less disruptive for a modern-day developer than the Erlang version. It’s certainly been a great journey since 2011, and many success stories have emerged from being able to use Erlang modules in Elixir code to boost your applications, such as Nerves, which helps you to build embedded software, and the web framework Phoenix. This language has proven itself to be really good at managing millions of simultaneous connections: in 2015, Phoenix reported managing 2m WebSocket connections, while, in 2017, Discord scaled Elixir to handle 5m concurrent users. Elixir is already used by big companies, such as Pinterest, Moz, and even some banking systems.

Three decades later

So, yeah, thirty years ago, 3 people—Armstrong, Williams, and Virding—created a language that solves web problems that we’ve only had access to for just under ten years. Now, thanks to Valim and all the Elixir contributors, we can take advantage of a language that’s much easier to learn and master for developers who are used to newer ways to write code. Who says experience doesn’t always win the day?

For further information, visit:

• erlang.org
• elixir-lang.org
• sitepoint.com/an-interview-with-elixir-creator-jose-valim
• cult.honeypot.io/originals/elixir-the-documentary
• joearms.github.io/published/2013-05-31-a-week-with-elixir.html

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by Victoria Roussel