Why use elixir?

Previous post: What is Elixir? An Introduction

In this post we’ll see why elixir is worthwhile using.

We already know elixir it’s a solid choice to build distributed systems but why learn a language that isn’t popular? Or you may even wonder if most projects don’t even need to scale and the ones that do will surely have the money for devOps right?

Well most businesses don’t raise money from investors, so no, you should never plan for having loads of money, on the contrary you should plan to be as frugal as possible and then if you even get to raise money you’ll actually be in a better position to negotiate as your expenses are low.

Lower costs/Scalable

Applications using elixir are able to server more users per server than in other languages, this means that you can spend less money in servers: Save money using elixir – The benefits of the technology, or you could think of it the other way, it’s more scalable.

Popularity and Productivity

One may think that using a popular language is an advantage. This comes from the notion that more is always better:

If we have more developers => We can do more work

If we have more resources => We can do more work

If we have more tools => We will get more accomplished

All of these can basically be reduced to:

More money => More accomplished

But that can’t be true, if companies with more money always won, then why startups succeed? Shouldn’t they always be killed by bigger companies?

Well in short terms startups deliver much faster. The point is that by using a much powerful language you can beat the competition. When I read these two posts all I could think about was elixir:

Beating the Averages

It must have seemed to our competitors that we had some kind of secret weapon that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.

Paul Graham

Over and over I read in forums about programmers who use elixir/functional languages saying they won’t ever come back. So I started wondering why? I finally arrived to these conclusions: if experienced people are saying they would never come back to a mainstream(object-oriented) language, is because first they don’t have to(don’t have a problem finding a job), and second they must have seen the “light”. It would be like asking the caveman who escaped to comeback.

This and the fact that it hasn’t gone mainstream sorts of creates a cool dynamic in the community, where the average quality of programmers using elixir is higher, as long as elixir isn’t “popular” [1]

Revenge of the Nerds – Paul Graham.

There are, of course, projects where the choice of programming language doesn’t matter much. As a rule, the more demanding the application, the more leverage you get from using a powerful language.

Paul Graham

Taking into account that they were written in 2002, nowadays you could replace:

C++/Java => Python, for Python => Elixir

So just as python was ahead of java/c++ in 2002 in terms of productivity, nowadays Elixir is ahead of Python/Ruby.

Specially since all the things he mentions about Lisp (and more) apply to Elixir.

When the underlying technology is fundamentally different, you’re playing a whole different game, it’s the difference between kicking a ball out of the stadium playing baseball vs trying to do the same in a football match, we can do things in elixir that we will never be able to do (realistically) in other languages.

In the field of programming we always talk about abstracting things, and each time we go up a level of abstraction we can accomplish much more.


You can also develop a flexible architecture. Unlike [insert popular framework here], that sorts of makes you build a monolith architecture. With a flexible architecture you’re basically future proofing your codebase. However you want to change your systems you’ll be able to: Elixir in times of microservices

Real time

In elixir you can build real time features, like a chat app. Discord did it. This allows you to do things like: live notifications, or updates.


It can even simplify your front end in some cases: Phoenix’s LiveView: Client side elixir at last


Final thoughts

Asking if you should learn elixir because your project is small is a relative question. It’s like me asking you if I should learn how to drive if I’m going to the store around the block. It depends on my future goals really, not just the current situation.

If on the other hand you’re already have systems in place you can take a look into: Elixir – Phoenix for Decision Makers

Posts I found while researching:

The Hundred-Year language – Paul Graham

Ten companies that use Elixir in production

Why Pinterest just open-sourced new tools for the Elixir programming language


[1] The python paradox explains this phenomenon.

What is elixir? An introduction

Elixir is a functional, concurrent programming language used to build distributed, fault-tolerant applications.

Every time we see somebody talking about elixir we see these keywords, hopefully by the end of this post you will understand why. In this post I’m going to explain how Erlang came to be, and how elixir builds on top of that.

Before learning about elixir let’s talk about Erlang, the language elixir is based on:

Erlang is a language designed by Ericsson in the 1980’s with the goal to build a telecommunication network.

Elixir code compiles to the Erlang Virtual Machine bytecode, these machine was originally built for the Erlang programming language. Because they compile into the same code, they share the same core functionality.

Here’s an (old) video explaining the use case Erlang was originally built for, machine switches:


Erlang was build to make systems for a rather constrained environment. Some of the constraints at the time were:

Fault tolerant: The system has to be available 24/7, 99.99% of the time. We use supervisors to restart processes immediately, the system had to be highly available with virtually no down time.

Concurrency: The computers had very low amounts of memory, so processes had to be light weight and isolated from each other(terminating a connection shouldn’t kill all other calls/processes)

Distributed: The programs/processes in these computers needed a way to communicate with practically any node in the world, as anyone could make a call and the system needed a way to make the distributed communication work. If a user connected to machine A wanted to talk to a user connected to machine B, we needed a way to make these two machines send messages to each other, and coordinate the actions to make.

To better convey some of these points, see how the creator of elixir explains what is possible:

Out of necessity to satisfy this requirements it gave birth to parts of the language:

Requirement => Language part

  1. Concurrency =>Processes: allow us to have concurrency since they’re isolated.
  2. Fail Fast => Supervisors: allows processes to die rather than trying to catch exceptions.
  3. Fault Tolerant =>Applications: Supervisors allow us to restart applications with a working state when they fail.
  4. Distributed => Message passing: allows us to build distributed systems, since we can pass messages between nodes easily.

And elixir has all these features too. So why elixir then?

I recommend this article: Why Elixir?

As you read is basically productivity, elixir comes with tools that help you be very productive. To name a few: iex, mix, hex, logging. It’s a very important  for the community to improve our tooling, because this ultimately lets us focus on what matters.

So when thinking why use elixir instead of Erlang is important to keep mind two additional things besides productivity:

Compatibility: Elixir will always be compatible to the upcoming versions of the VM, because of this compatibility we can call Erlang code from elixir at no additional cost.

Extensibility: Elixir knows a programming language can not have all the features developers will come up with, so with macros(meta-programming) it allows developers to build their own programming constructs for their domain problems.

In the next article I’m going to give more details about why use elixir.

You may be interested in:

Why you too should learn elixir

Concurrency and parallel processes

In this post I’m going to explain what is concurrency, parallelism and their differences.

First watch this video:

You can think of concurrency as two things that exist at the same time. For example when we use our computer we have different programs open, we might have chrome, and excel. So you can switch back and forth between them, because using one doesn’t mean we have to exit from other programs. That is concurrency, two or more things existing at the same time frame.

So if you think about it, concurrency is needed to do parallel processing, you need two processes to exist at the same time if you want to run them on parallel. (I exist, therefore I run? Bad joke I know..)

For instance when we leave music running in a chrome tab and then do something else in another, the tabs are concurrent with each other, they both exist simultaneously but we can only interact with one of them at any time since computers do not allow having multiple mouses running in parallel.(If you connect a second mouse to your PC, you don’t see a second mouse popping up in your screen)

If you switch super fast back and forth between concurrent processes you can give the user the illusion that the processes are running in parallel, which is what computer did before having multi-core processors.

You may be interested in:

Understanding Concurrency and Parallelism in Elixir


The Basics of Functions: Named and Anonymous

There are multiple ways to define a function in elixir, before doing that let me describe what a function does.

Functions are the backbone of elixir, what they do is get input data, transform it, and output new data. Ideally each function should do one transformation only (Single Responsibility Principle).

Named functions

These have to be defined inside a module like:

defmodule Cache do
  def hello do

Note: In elixir you don’t have to write a return statement, the value of the last expression in a function is the returned value.(if no value is returned then functions return ‘nil’ by default)

Quiz: Why did we get an ArgumentError?

How to define a named function in one line:

defmodule Cache do

  def hi(name),  do: "hi " <> name


Notice: the coma and the semicolon.

Anonymous functions

These are really easy to define:

fn (a, b) -> a + b end 

fn -> :world end

fn a, b -> a + b end

In the first function, “a” and “b” are the input values and the output is the result of a + b

The second function is equivalent to the ‘hello’ function above.

The third function is the same as the first, but I believe the first one looks more clear with the parentheses.

We can assign anonymous functions to variables, and call them with the variable name. Let’s do that with the second function.

So all we had to do was:

helloanon = fn -> :world end

The first time we try to call “helloanon” we get the same value:

#Function<20.128620087/0 in :erl_eval.expr/5>,

that we got when we declared and assigned the variable.

This happens because “helloanon” is not a function, is a variable that references the anonymous function. So we can not call “helloanon” as we did with ‘Cache.hello’ function previously.

In other languages it would make sense to call: helloanon(), right?

But that doesn’t work either, we have to call it with a dot + parentheses: .()

The reason for this is because in elixir we have a namespace for variables and a different namespace for functions. So you can have a variable and a function with the same name! And what happens if we have a variable pointing to a function and a function with the same name you may ask, well that’s what the .() notation is there for:

To differentiate calling a named function from a referenced function(anonymous).


Unlike named functions, anonymous functions are scoped from the context from which we created them. (This means we can use environment and variable values from the moment when we created the anonymous function). In a sense named functions are isolated from their calling environment.(We have to give them all context as parameter values)

To illustrate this better consider the following module:

defmodule Calculator do

  def duplicate(a), do: 2 * a


and watch this:

As you can see even when we change the value of ‘a’ the anonymous function sticks to the value ‘a’ had when we created it.

So in both type of functions you can pass parameters but only on anonymous ones we can use context variables without having to pass them.

Now these two functions are not equivalent since, the ‘Calculator.duplicate’ has 1 argument and ‘duplicate’ doesn’t have any. The point wasn’t to make them equivalent, the point was to illustrate how environment variables affect anonymous function if we use them.

If you’re not using environment values an anonymous function will act as a named one if they have the same parameters, body, etc.

Thanks to the following posts: Why do we use a dot to call a function? , Anonymous functions, the dot, and parameters both from the elixir forum.

The next post is on a very important property of elixir functions: Arity