Elixir, other than being an alchemical cure-all, does double duty as a programming language that’s good for fast, resilient, parallel computing. It has all the syntactical charm of Ruby, with the power of an alien (actually Swedish, but close enough) technology. But why am I learning Elixir now, after so many years of Ruby?

To understand why Elixir is particularly compelling to learn right now, you have to know a bit of the context of computing. For a while, from roughly the 1960s through the early 2000s, there was a golden period of computing hardware advancements in which processing “power” doubled every two years. It was fantastic unless you liked keeping your computer for longer than a year. However, unlike power levels in Dragonball Z, processing power is nuanced.

What everyone thought of as processing “power” was actually the clock rate, or how many operations a processor could do in a second, and the doubling technically referred to the number of transistors in a processor doubling every 18 months, commonly known as Moore’s Law. But processors weren’t being used the way we use computers nowadays – with hundreds, or thousands of things going on at the same time. The way some people use a single browser window with hundreds of tabs would be impossible on the hardware of yesterday. But that’s rarely the only thing you have going on your computer at once – and that’s what you know of! Our computers are always hard at work under our very noses, and the hardware has to support all that multitasking.

Your computer is like a busy restaurant kitchen. Whatever the customer orders has to show up on time, but there are a thousand other things that have to happen meanwhile. Vegetables need to be chopped, soup stock heated, meat sliced. When things go wrong, a backlog of orders threatens to swamp the kitchen, slowing everything down. There are a few different ways a computer – or a kitchen – can handle workloads.

Sequential Computing

The kitchen has one cook. Let’s say they can cook 1 meal per minute. That’s a fast cook! But since there’s only one cook, they can only work on one thing at a time. So if you have 60 people waiting on their meals, the last person is going to get their meal in an hour. That’s no good. They might be a VIP or a restaurant critic.

Concurrent Computing

The kitchen still has one cook, but the cook is crafty and can juggle multiple things at once. Someone ordered a soup and a taco? No problem, they’ll start heating the water for the soup, then they’ll switch over to make the taco. By the time the taco is done, the water is hot and ready to go, so customers can get 1 taco and 1 soup in the time it takes to make just the soup.

Parallel Computing

Business is booming and even the blindingly fast, crafty cook can’t keep up, so they hire more cooks – let’s say 2 (for now). Now they can do twice the amount of work at the same time! And best of all, they can still use concurrent techniques to make efficient use of their time on multiple tasks.

So what people thought of as “performance” doubling was actually just the single cook getting faster and faster. Which is great, but what if you want to watch YouTube while printing something and messaging your buddies? Well, that single cook – in our case, a single processor – is going to get overwhelmed fairly quickly.

So processor manufacturers started adding cooks.

You may have heard of processor cores. They are analogous to the cooks in our metaphor. Whereas processors of yore only had one core, processors now have sometimes over a hundred cores in the same piece of silicon. This abundance of “cooks” lets your processor speed things up in a different way than just running a single task faster. And what’s more, processor manufacturers effectively stopped being able to manufacture cores that were faster on a pure operations-per-second basis, so they had no other choice if they were to remain competitive – they had hit the limitations of physics in terms of clock rates.

Now, on the software side, many programming languages had only been designed to take advantage of one processor core at a time – sequential computing, basically. While processor cores were doubling in clock speed every 2 years, this wasn’t much of a problem. If there was a performance problem, programmers could punt it down the line to their future counterparts who would have exponentially faster hardware at their disposal.

But when the last gigahertz marketing campaign died, sequential computing wasn’t too far behind. There are a lot of clever ways to get around this – asynchrony and threads, for example – but it turns out that it is not really something you can tack onto a programming language later. To go back to our analogy, if you have two chefs and they both try to use the ladle at the same time, a fight could break out, or if they both receive an order at same time, one might use up an ingredient before the other gets to it. A properly parallel programming language has to be able to orchestrate all of that at the same time.

Enter Erlang. Erlang, Elixir’s parent language, so to speak, was invented from the get-go in 1986 to handle many thousands of concurrent connections because it was born in an environment that required it – telephony, the original social network. To crib a bit from Wikipedia, it specifically needed to be:

• Distributed
• Fault-tolerant
• Soft real-time
• Highly available, non-stop applications
• Hot swapping, where code can be changed without stopping a system.

…in order to comfortably handle and maintain switches between phone users. One particularly important idea in Erlang is that everything is a process. You could almost say that everything gets a single cook.

Elixir inherited all of that from Erlang, and a heavy dose of Ruby sensibilities from its creator, José Valim. Ruby and Elixir are both elegant programming languages for different reasons, but Elixir’s inheritance means that it’s better suited for parallel computing workloads that are becoming more and more important as hardware diversifies past the gigahertz wars.

Elixir provides particularly compelling bait for web developers who are looking to provide near real-time user experiences while scaling up to possibly millions of users at the same time.

If you’re interested in learning Elixir, you can start at https://elixir-lang.org/. I can personally recommend Dave Thomas’s book, Programming Elixir 1.6 for its wonderful exercises and clear, but concise writing style (if you’re in the business of buying programming books, you can also save yourself a lot of time and money by getting your books through an ACM membership). You can also find Elixir on Slack and Discord. Otherwise, I’m just starting on my Elixir journey, so feel free to geek out about it with me @briankung on Twitter!