A (Very) Brief History of Erlang

Despite launching in 1986 (a mere two years after your writer was born), I only came across Erlang in about 2017. As a Web Application Developer, I came across it in what a lot of likely scenarios would be for everyone else: RabbitMQ. At that point, we were using RabbitMQ on a project that had a particularly complex and time-consuming ETL Process. We needed speed, concurrency, and secure record locking. Later, I discovered the reason why RabbitMQ could achieve this was that it was written specifically in Erlang for these requirements.

Given that it was listed as the second-highest-paid mean salary in 2025, what exactly is it, and what specific use cases does it have?

The Landscape

The starting point for any story is looking at where the gap lies. PHP came about as a scripting tool to dynamically create HTML pages, JavaScript started out as LiveScript to allow a runtime within the browser. Since those days in 1995, both of those languages have totally evolved to unrecognisable levels due to the nature of their requirements. In a similar way, Erlang was created specifically for Communications. At this point, telecommunications had a requirement for code that could handle massive scaling, ultra-high concurrency, and real-time execution. Its birth came from the development of the AXD301 ATM Switch, created by Ericsson, which needs what is referred to as “the nine-nines” availability. In layperson’s terms, that is a hardware switch which it’s software requires an availability rate of 99.9999999%. Such a programming language to do this didn’t exist.

Evolution

Erlang really started to get traction as Ericsson made the decision to make the language open source in December 1998. The language was out, and with it came external projects. From this point, materials gradually emerged to give the outlines on how to use this language, and what its strongest use cases were.

“Let It Crash”

Let it burn!OK, here’s a novel concept for you: you’re encouraged to let processes fail. I come from a land where defensive programming is absolutely essential to application authoring. It’s at this point that “I get it”, because Erlang isn’t designed as a classic server-based backend language. The reason why it’s acceptable for crashes is that developers are encouraged to write code in small chunks that can all be run in isolation. Running the application should be supervisor systems that then look for crashed threads or processes, which are then rebooted. It’s this philosophy that results in high availability: it doesn’t matter if a payload isn’t completed, just that the necessary data is transmitted at some point. This is how Erlang came to exist so prevalently in the Communications Vertical markets: the resilience it creates is the reason why RabbitMQ, a messaging client, is written in Erlang. It also explains why Meta’s WhatsApp is written in Erlang, or why popular messaging app Discord is written in Elixir (a slightly modified Erlang that still runs in the BEAM VM), and indeed why I already had some background knowledge in Erlang’s use cases, given that Vonage is a Communications-Platform-as-a-Service (CPaaS).

Concurrency

How is it able to handle this level of concurrency? Traditional Web Application developers might have come across Async/Promise systems, such as in C# or the single-threaded Node.js. This isn’t how Erlang works: instead of Operating System threads, it has its own VM called BEAM, which handles lightweight individual processes. Because BEAM can switch between them (similar to how something like PHP Fibers brought concurrency) at lightning speed, it can handle millions of these processes at a time.

Watch It Break

The fault-tolerance I mentioned previously is handled by supervision trees. This internal design pattern is part of the Open Telecom Platform core of Erlang - think of it as the equivalent of the standard library. There is a network of supervisors that monitor processes, which emphasizes the importance for developers to look at restarting processes instead of trying traditional try-catch style error handling.

Bulletproof: Hot Swapping

Sometimes features I’ve never encountered before in programming languages really blow my mind; I remember finding out that you could monkeypatch the core language of Ruby at runtime, which I just couldn’t wrap my head around. Similar to this discovery: remember that fault-tolerance is at the heart of Erlang? Well, when you have Erlang running, you can swap out live code without stopping the VM. If you’ve ever wondered how WhatsApp handles sending a ton of updates with seemingly zero downtime, this is your answer.

Conclusion

We’ve essentially covered the basic philosophy of what has made Erlang the way it is. From this background, it makes the language an ideal choice not only for messaging and communications, but anything else that requires the same level of uptime and fault tolerance. It also has a great application when used in databases, which would explain why both CouchDB and Riak are written in Erlang. So, for the ambitious developers out there who are thinking of writing their own IoT backend, or perhaps looking to integrate Network APIs into their stack, we’d love to hear what you’re working on.

Further Reading

Developer Documentation for Network APIs

Erlang Documentation