Basics and background on the Elixir programming language – An interview

This all sounds very abstract. Can you give a concrete example of how BEAM and Erlang make applications distributed, highly available, and fault-tolerant?

Certainly. BEAM and Erlang implement the Actor Model. Processes communicate exclusively through messages. Each process can send messages to other processes and has an “inbox” for messages received from other processes.

As a Java developer, Akka comes to mind, which also implements the Actor Model.

Exactly. The difference is that the Actor Model in Erlang is implemented at the language and runtime level. It is thus embedded in the language and native to the runtime, being the only means of inter-process communication. Perhaps I should briefly explain the term “process” in this context.

In the Erlang world, a process refers to a virtual thread, i.e., a thread managed by BEAM and not the operating system. Therefore, processes in Erlang are very lightweight, and it is common to run thousands of them simultaneously. Moreover, processes can be transparently distributed across different nodes in a cluster. A process on another node in the cluster behaves the same way as a process running on the same node.

So, we’ve clarified how Erlang enables the development of distributed systems. What about the other two properties, fault tolerance and error tolerance?

These two properties go hand in hand. In short, processes can monitor and control other processes. The “let it crash” philosophy is implemented, meaning a process that encounters an error simply “dies” without worrying much about error handling. The monitoring process takes care of error handling, usually by restarting the corresponding process.

Now we’ve learned a lot about Erlang and BEAM. Where and how does Elixir come into play?

It might seem a bit strange that I’m focusing so much on Erlang, but it’s essential to understand that by using BEAM, everything I’ve mentioned about Erlang also applies to Elixir. Now, let’s get to the differences. Erlang and Elixir mainly differ in syntax and ecosystem.

As mentioned, Erlang’s syntax is over 30 years old, not quite fresh. On the other hand, Elixir has a modern and, in my opinion, easily understandable syntax heavily inspired by Ruby. This is partly because there are relatively few language elements and also due to the extensive use of pattern matching.

Often, there’s precisely one way to efficiently solve a problem. Following the functional paradigm, it’s straightforward to “compose” complex functionality from simple (partial) functionality. And if a language element is missing, you can implement your own language elements through metaprogramming, i.e., writing Elixir code with Elixir code. Metaprogramming makes the language powerful and extensible. For example, domain-specific languages can be created this way.

This is coupled with a robust ecosystem with excellent documentation and a welcoming community. At the center of the ecosystem is Mix, Elixir’s build tool. It allows scaffolding, testing, building projects, dependency management, and much more.

When is Elixir not a good idea?

It’s challenging to make a blanket statement because, in my perception, Elixir has evolved into a versatile language lately. For example, Embedded Elixir can be used to program microcontrollers, and Numerical Elixir can perform calculations on multidimensional arrays. However, as mentioned, the focus is on distributed systems. Elixir is often used with Phoenix, a web framework, to create web applications.

With few exceptions, it can be said that Elixir is not suitable for large numerical calculations and low-level applications. Elixir excels when used on the server side.

What is Phoenix?

Phoenix is a framework, or library, for creating web applications. Phoenix drew inspiration from Rails, a similar framework for the Ruby programming language. Like Rails, Phoenix is primarily designed for server-side rendering following the Model-View-Controller pattern. LiveView, introduced some time ago, blurs the boundaries between server-side and client-side rendering, providing an alternative for single-page applications.