left-icon

Elixir Succinctly®
by Emanuele DelBono

Previous
Chapter

1
of
4
A
A
A

CHAPTER 1

Introduction


A short history of Elixir

Elixir is a relatively new functional programming language that runs on the Erlang virtual machine. For a look into the history of this young language, we have to start in the 1980s.

It was 1982 when Ericsson, the leader in telecommunication systems at the time, was looking for a new programming language for its telephone switches and routers. Ericsson tried various languages, but none completely answered the requirements of availability, robustness, and concurrency.

The company decided to implement their own languages, and in 1986, they began developing Erlang, using Prolog. Over the next few years they developed a series of prototypes that would eventually become the foundation of what Erlang is today.

In 1990, the first version of Erlang (rewritten in C++)  was used in a real project. It was a mobility server for Digital Enhanced Cordless Telecommunication (DECT) used in private offices. The project was successful, and was used to gather feedback for the next version of Erlang. This is when the Open Telecom Platform (OTP) framework was developed.

At that time, the core team was composed of three developers: Joe Armstrong, Robert Virding, and Mike William.

Erlang was used a lot in Ericsson until 1999, when they decided to ban it inside the company in favor of a more popular language. This decision was in some ways the trigger that permitted Erlang to reach outside of Ericsson and become a commonly used language.

Erlang became open source, and its peculiarities were suddenly appreciated. To understand why Erlang was (and still is) very appreciated, we have to remember that in 1998, Ericsson announced the AXD301 switch, which contains over a million lines of Erlang code, and was reported to achieve the nine "9"s availability, meaning that it was "down" for only 0.63 seconds in 20 years!

How could such level of availability be achieved?

Joe Armstrong talked a lot in his speeches about robustness, and he explained why Ericsson had to write its own language. The main driver was concurrency: if a language is not designed to cope with concurrency from the beginning, it's very difficult to add it later; whatever developers try to do it will create problems or be sub-optimal.

Erlang was designed with concurrency at its core: processes are truly independent, there are no penalties for massive concurrency, and distribution and concurrent behavior work the same on all operating systems.

With these principles, Erlang developed the maturity and stability it has today. These peculiarities are exactly what today's developers need to build applications with high availability and scalability.

And here, Elixir enters the scene.

One problem with Erlang is the syntax of the language, which is very different from other programming languages we are using today. This is probably one of the factors that pushed Jose Valim, a Ruby developer, to investigate Erlang for designing Elixir.

In 2012, Jose Valim was working on a research project for Plataformatec, trying to improve the performance of Ruby on Rails in multi-core systems. However, Ruby was not designed to take full advantage of multicore systems. So Valim took a look at other platforms to better understand how they solved the concurrency problem, and eventually, he fell in love with the Erlang Virtual Machine.

As soon as Valim started using Erlang, he noticed that the language was missing some constructs available in other languages, and that the ecosystem wasn't very rich like Ruby or Nodejs (https://nodejs.org). That's when he decided to create Elixir.

The point was to design a modern functional programming language that runs on a battle-tested solid platform: The Erlang Virtual Machine.

Elixir has grown a lot in the past several years—we have version 1.8, a package manager, lots of documentation, and a growing community.

The core team of Elixir releases a new version about every six months. There is a mailing list where you can read about what decisions are being evaluated, and you can contribute with new ideas and proposals (and pull requests as well).

We said before that Erlang lacked a package manager. Elixir introduced Hex, a package manager that works for both Elixir and Erlang. At the time of writing, Hex has more than 8,000 packages, but it’s growing fast, and more packages are published every week.

You can find instructions for downloading and installing Elixir on the official Elixir website, as well as documentation and tutorials to help you get started. 

To install Elixir on your computer, you have to install Erlang as a prerequisite, since Elixir uses the same virtual machine. The installation procedure depends on your operating system, and you can find detailed instructions here.

Once installed, you can see if everything works by typing iex from terminal. If it works, you should see something like this:

Figure 1 – iex REPL

Figure 1 – iex REPL

Why is Elixir so interesting today?

Why are Elixir and Erlang so interesting for today’s applications? And how can a platform developed more than 30 years ago—when the Internet had just been born—be useful today?

As said before, Erlang and the BEAM (the virtual machine that runs Erlang code) were designed with three ideas in mind: concurrency, fault tolerance, and distribution transparency.

Concurrency was needed by the domain: Ericsson is a company that builds telephone switches and routers, and one switch must be able to handle different phone calls concurrently. To be able to do this, every process must be independent from others, and must have its own private memory space. In Erlang every process is a sort of private space in which the code runs without sharing its data with other processes. To communicate with another process, it must send a message. The message arrives at the inbox of the destination process, and when the process is ready, it receives and processes it. This also means that inside a process, the code is always mono-thread/mono-process, and there's no need to sync, lock, or monitor the execution!

This is a very helpful simplification compared to Java or C#, in which concurrent or multi-thread programming is difficult to handle and debug.

Another need of Ericsson’s was to avoid communication interruption in their switches during calls, and if something accidentally goes wrong, they needed to restart the process as soon as possible. This is exactly what the Erlang VM does: in case of failure (exceptions), it kills the process and restarts it immediately, without affecting other processes. This feature is even more powerful, and gives the developers the ability to do hot updates to the application. That means you are able to change the code of your application in production without stopping it!

These processes are also easily distributable; the fact that a message is routed to a process that runs in the same virtual machine, or that is routed to a virtual machine that runs on another server, is completely transparent. Developers can start developing the application considering that all processes are running on the same machine, and then spread them to multiple machines (for example, for scalability) with little effort.

Consider the actual web applications: they usually are highly concurrent, and sometimes they need to be deployed on different machines for reaching performance needs. What programming platforms give the developer these facilities? Very few. One of the most-used programming languages for writing web applications is Node.js, which is a mono-thread programming language. For the developer, it’s quite easy start with it (single thread apps are easy to understand), and it doesn't use all the power of your multi-core/multi-CPU server.

Today, most developers talk about microservices, but how hard is it to develop a solid microservice application? Writing a microservices application is hard because there isn't a single platform that developer can use to write all of the application. How do you make services communicate easily and reliably? Usually, third-party applications are needed (such as Message Bus, API, and brokers).

Elixir and Erlang, with their virtual machine, already have all the facilities that are needed to develop microservices applications inside—no need to install or configure other tools.

Another architecture that is gaining consensus in these years is the Actor Model. There are open-source frameworks for dealing with this architecture. The most famous is probably Akka for Java/Scala and Akka.NET for .NET. It works, and it’s battle tested and well maintained, but what if you don't need a framework because the platform already has all the stuff built in? The Erlang Virtual Machine has all the facilities and components needed to build applications using the Actor Model pattern—battery included. It's a great feature for the same reason that concurrent-oriented programming languages should be built with these concepts from the beginning—adding them later is not a good option.

Today these features are mandatory in most applications; a web server is intrinsically concurrent and must deal with failures.

So even if it was built more than 30 years ago, the Erlang Virtual Machine is still one of the most interesting platforms for developing the applications that we need, and Elixir is a new functional programming language with a modern syntax (in some ways it resembles Ruby) that runs on one of the best virtual machines around.

Scroll To Top
Disclaimer
DISCLAIMER: Web reader is currently in beta. Please report any issues through our support system. PDF and Kindle format files are also available for download.

Previous

Next

TABLE OF CONTENT
About the Author
1. Introduction
2. The Language
3. The Platform
4. Sample Application