This is a transcript from an interview with the creator of Elixir, Jose Valim by Darko Fabijan at Semaphore, you can visit their website & listen to the interview here: https://semaphoreci.com/blog/elixir-creator-jose-valim In this episode of Semaphore Uncut, José Valim, the creator of the Elixir programming language shares with us insights on developing Elixir, from its inception to the road ahead.

José is the Chief Adoption Officer at Dashbit, speaker, and the author of three technical books.

We talked about:

• How Elixir was born

• Elixir’s functional roots

• The role of Erlang VM

• Modeling concurrency in Elixir

• The milestones of creating a new programming language

• Extensibility as a must

• Elixir macros enable the ecosystem

• Tips to stay focused

Listen to our entire conversation above, and check out my favorite parts in the episode highlights!

You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.

Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

Edited transcript

Darko (00:02): Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today, I am excited to welcome José Valim. José, thank you so much for joining us.

José: Thanks for having me. I am José Valim, and I believe most people know me as the creator of Elixir. I am also the chief adoption officer at Dashbit. We are a company where we are helping startups and enterprises run and adopt Elixir, in different stages, different industries, and so on.

How Elixir was born

Darko (00:45): Can you give us a bit of history, how you ended up doing what you’re doing and how that progression came to the point where you felt that the world needs a language that will address a certain group of problems?

José: I was a Ruby/Rails developer and at the time, back in 2008, we were starting to hear a lot about concurrency and that machines, they’re going to have multiple cores.

I knew from the experience of maintaining Rails and other root projects that writing multi-core software, which is software that runs on all cores with Ruby, was not really straightforward. So for example, we are trying to make Rails thread-safe. Sometimes we would get a bug report like, “When are we having a spike in production, and we deploy a new server, we have this error, but we don’t have this error any other time.

And that means when there’s a spike in production in the part of the server, there was a bunch of requests coming at the same time and that is going to exercise some code paths that it’s very hard to exercise otherwise that would make bad things happen. And those things, they were hard to debug, hard to understand, hard to fix. So, I started looking. Originally I started to say, “Okay, if concurrency is going to be important, I want to see how people are solving those problems.”

Elixir’s functional roots

Throughout this journey, I’d like to say, there were two particular moments of like no return where I said, “Okay.” That effectively changed the way I thought about software. The first one was functional programming. And functional programming can mean a lot of different things to a bunch of people. But to me, what it meant at the time was immutability.

Because a lot of the time, when we are working with most languages that are imperative languages, Ruby, Java, JavaScript, Python, C, we have a lot of issues with concurrency because we are changing things in memory. So it happens that if you have two threads trying to change the same place in memory, you have two cores in your machine trying to change the same place in memory they can corrupt that memory, or they can put in a state that is not understandable.

In functional languages, generally, we avoid doing that. So everything’s immutable. If you have a list of three elements, and you delete one element, now you have a whole new list with two elements. That was when things clicked for me. I understood like, “Wait, if I’m not mutating my data structure, if everything’s immutable, there’s a whole category of problems that I have been debugging and trying to fix in the past that they no longer exist.”

And to me, that’s like my favorite way of solving problems. I can fix problems, but if I can disappear with the root cause of the problem altogether, yeah. I’ll take that. So I was like, “Okay, this is great. If I’m following those principles, I think my software is going to be better. It is going to be ready for this multi-core future.” And that was the first point of no return.

The role of Erlang VM

And the second point of no return was when I found out about the Erlang virtual machine, and the thing was the focus of the Erlang virtual machine was not concurrency. It was distribution and it has been distribution for three decades. is that back when I was exploring those things, everybody was talking about concurrency.

Imagine that you’re writing your software and you wanted to use a single machine as efficiently as possible. So if the machine has eight cores, you’re going to leverage concurrency. But what happens when that machine is not enough? You cannot run everything your system has to do on a single machine. Or if you want to have two machines, because you want some resilience. They want to have some robustness there not to have one single machine in production, you need to have multiple machines.

So how can you make those multiple machines now communicate and collaborate together? That’s exactly when distribution comes in. Everybody was trying to solve the issues with concurrency, but we have this virtual machine, the Erlang virtual machine, that has already solved those issues, and they are now talking about distribution. So they are ahead of everybody. And I still believe the virtual machine in this sense is still ahead of everybody today.

And then I said, “Okay, this is the platform that I want to build software with.” So I started using more and more the Erlang virtual machine and the Erlang language. I found out about some places that I would like to improve the language or there were some particular kinds of software, some particular kinds of constructs that I felt were important and were not there. And that’s when I decided to start working on Elixir.

Modeling concurrency in Elixir

Darko (12:01): What are your experiences with people generally wrapping their minds around concurrency and using it? Can you share how that part of the language is being adopted in use? What are your experiences?

José: One thing that’s worth talking about is that Elixir doesn’t solve all concurrency issues. You don’t just write the software and they are no concurrency issues whatsoever. It does remove the majority of data issues, but you still have concurrency issues. But I don’t know if there’s a better word for this, but I like to say those are natural concurrency issues.

It’s like, imagine there is a cup of glass on the table. Two people are going to get it at the same time. You can’t split the glass. The water’s going to be everywhere. Those are natural concurrency issues, and they exist everywhere.

But the way that you model concurrency issues in Elixir is by having this idea of actors. In the community, we call them processes. Those are lightweight processes. They’re not operating system processes, but I’m going to go into the less confusing term in general: actors. We have actors and actors, they communicate with messages. It’s such a natural way to think about concurrency that once you get familiar with how Elixir models concurrency and approaches concurrency, you’re actually better prepared to think about those natural issues that happen. It’s going to give you a mental framework to approach those problems in general.

I think the mental framework is going to h