Why You Too Should Learn Elixir

Jul 8, 2018 - 8 min read
Why You Too Should Learn Elixir

Some time ago, I started learning about the Elixir Language, and Functional Programming.

I feel like Ruby on Rails is getting old, and I’m not saying that as a bad thing. It’s just that it lost its cutting edge aura and it toned down its coolness factor (if that’s a thing) as far as I am concerned.

Or maybe it’s just me trying to find something new and exciting to learn.

I want to share my opinions on why I think learning the Elixir language is good for you.

Why should you learn Elixir?

If your goal is to get hired by the big companies and receive a fat paycheck, I’m sure you’ve already got one eyebrow up.

A quick look around the web, makes it obvious that there are not that many jobs for Elixir, so why should you bother?

Well, it’s not because learning Elixir can get you a better job tomorrow. It’s because it makes you a better developer, and that’s much more important career goal.

That is especially true if you’ve been mostly programming in an Object-Oriented language la Ruby.

How Elixir can make you a better developer

If you’ve only worked with Object-Oriented languages, Elixir sets your brain on fire because it forces you to learn a new paradigm.

I’m going to tell you more about functional programming in just a minute, but trust me when I say Elixir can blow your mind.

It gives you a different perspective on programming in general. However, the best part is, it can transform the code you write in your OOP language of choice.

What is Elixir

Elixir is a functional programming language developed by José Valim which looks similar to Ruby. You don’t have to be a Ruby developer though to find that Elixir code is remarkably easy to read.

It’s also an alternative language for the Erlang Virtual Machine (BEAM).

If you’re a Ruby on Rails enthusiast, you should know that Elixir has a similar web framework called Phoenix.

What is Erlang

Erlang is not just a language, Erlang is an open-source, general-purpose development platform.

It was built for the telecom industry by Ericsson, and it’s been doing a fantastic since 1986.

It has built-in support for concurrency (cheap context switching), distribution (executes on different machines), fault tolerance (it recovers from errors), and it prides itself with nine-nines of availability (~31ms downtime/year).

Elixir vs. Ruby

The first thing I want to mention as a general principle is that you don’t have to go all in on a language. You don’t have to choose one over the other.

Every language has its pros and cons.

Elixir is not a better version of Ruby. It’s not a replacement for Ruby. It’s a new language with a different set of goals.

Compared to Ruby though, Elixir offers better performance since it’s a compiled language; better scalability, and high availability.

The code you write in Elixir is very explicit, meaning there is less magic. I find that very refreshing, coming from the Ruby world.

And the killer feature is, it uses all your CPU cores (e.g., you can run your tests in parallel).

Let us see some examples of Ruby and Elixir code.

# Defining a method in Ruby
def hello

# Defining a method in Elixir
def hello do

# A hash in Ruby
{a: 1}

# A map in Elixir
%{a: 1}

# An array in Ruby
[1, 2, 3, 4]

# A tuple in Elixir
{1, 2, 3, 4}

# Calling a method on an object in Ruby

# Calling a function in Elixir

# A Ruby lambda
-> x { x * x }

# An anonymous function in Elixir
fn(x) -> x * x end

# Using the each function in Ruby
[1, 2].each { |i| puts i }

# Using the each function in Elixir
Enum.each([1, 2], &(IO.puts &1))

# Defining a module in Ruby
module Example

# Defining a module in Elixir
defmodule Example

As you can see, there are similarities between Ruby and Elixir. But don’t let that give you the impression that you could use Elixir like you use Ruby, they are very different languages.

Elixir for business

There are a few reasons you might want to adopt Elixir into your business.

If you are building applications that need to be highly available (remember the nine-nines of availability), Elixir is an excellent choice.

Another nice feature is responsiveness. Your application can respond to requests regardless of how many clients connected to it.

It never crashes. Even if you have buggy code lying around, the rest of the application continues to work fine.

Elixir code is easier to grow and maintain, and this means lower cost.

Elixir for Rubyists

Elixir, because it’s a functional programming language, it makes it easy to write tests. That happens because state is immutable and you get to work with functions that receive data and return data (for the most part).

Code quality is higher not just because it makes it easier for you to write more and better tests, but also because it has a compiler that yells at you whenever something is not right.

As a Rubyist, it is straightforward to start writing Elixir code because of the familiar syntax it offers.

I find doctests amazing. Doctests are tests for your documentation. So if you have examples in your documentation, those run as part of your test suite and thus guarantee that examples are never misleading.

And more importantly, Elixir teaches you a new way to think about programming in general. Understanding functional programming as an OO programmer is not an easy task, but it’s worth the effort.

When to chose Elixir

Elixir is an excellent choice if you want to use Erlang, but you hate the syntax.

Another good reason is if you want to build highly distributed systems; systems that run on multiple CPUs/machines.

There seems to be a trend now in building chat systems, which is something that Elixir does well. Low latency applications like that.

As previously mentioned, highly reliable systems are also where Elixir shines. If you need your application to be up all the time, Elixir is probably your best choice.

When NOT to chose Elixir

If you need to build applications that rely a lot on number crunching, Elixir might not be your best choice. You’re better off using a language like C or C++, which are much better at CPU intensive computations.

Elixir doesn’t have such a diverse Ecosystem. For example, the number of repos for Elixir is currently about 36.000, while Ruby’s is at 1.500.000, and Javascript is at 5.000.000.

You would think that Elixir is excellent at parallelism, but it’s not. Its design goal is fault tolerance, not parallelism.

There is also the learning curve you need to take into account. Learning Elixir is not an easy task. It starts with functional programming (which is a vast subject), and continues with the OTP platform, and then the BEAM, and most likely Phoenix too.

Why learn functional programming

Here’s one reason, in the words of Joe Armstrong (author of Erlang).

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

However, there are other reasons too:


Functional programming makes concurrency possible by preventing both race conditions (where two programs race to get the same value) and deadlocks, where one program is waiting indefinitely, for the other to write a value.


Imagine a world where there are no mocks. How would your tests look like if you weren’t using so many mocks. Functional programming gives you that.

While you probably won’t get away without any mocks, there can be a lot less mocks in your tests since most functions have no side effects (i.e., there is just data in/data out).


Debugging is much easier when you don’t have global state. You can look at the arguments of a function, and you’ve got your state right there.

There’s no need to go digging through your app to figure out why things are the way they are.

If you’ve never seen Saša Juric’s “Solid Ground” talk before, make sure to add to your watch list. It is mind-blowing.

Easier to understand

Functional programs are made of small functions that perform simple, and well-defined operations on the data you pass to them.

You then compose larger programs by using these smaller functions like legos.

As a result, the larger program is much easier to read and understand.

12 Project Ideas
Cezar Halmagean
Software development consultant with over a decade of experience in helping growing companies scale large Ruby on Rails applications. Has written about the process of building Ruby on Rails applications in RubyWeekly, SemaphoreCI, and Foundr.

Related Posts