Interview with Jose Valim on Elixir

Jose Valim, lead developer of PlataformaTec and member of the Ruby on Rails Core Team, takes the time to talk with us about his experiences developing Elixir.

Jose Valim Desktop
EI: To start us off, just for fun -- could you give us a screenshot of your current desktop?

JV: I got this one (and probably my last 20 backgrounds) from :)

EI: Beautiful! So when and how did you start programming?

JV: I was kind of a late bloomer. I started programming when I joined university and my first programming language was C. From there I went to learn Java, C#, PHP until I finally encountered Ruby. Even though I spent some good time using those languages, like writing my thesis in C, Ruby was the first programming language that I really considered myself to be an expert. From then on, I continued learning and studying other languages.

EI: What gave you the idea to develop Elixir?

JV: It was really many factors coming together. Back in 2009, it was already very clear that we were looking into a multicore future and I was becoming unhappy with the tools to solve concurrency issues in Ruby. That's what led me to continue studying and looking at other programming languages.

Although I have already read and played with Erlang a bit, it wasn't until I read the fantastic Seven Languages in Seven Weeks book that I realized that I really wanted to be using the Erlang VM for writing those concurrent applications. And even better, by using the Erlang VM, I'd also get distributed applications almost for free!

From then on, I decided to put more energy into learning and studying Erlang and the underlying VM. I was quite happy with all the tools available but I particularly felt some of them were missing, like the ability for meta-programming and some extensibility mechanisms like protocols. That's how Elixir was born.

EI: And now, how would you sell Elixir to others? What are its most important advantages?

JV: Well, it depends to whom I am selling it. :-) In general, our main asset is the Erlang VM. We wouldn't have Elixir if it was not for the Erlang VM. Put that together with our meta-programming and extensibility mechanisms and you get a solid look of what are our goals and what we want you to be able to achieve with the language. I have recently written a blog post that goes over our goals in detail.

EI: Great, I'll be sure to check that out!

Given the Erlang VM, for which types of applications would you pick Elixir over Erlang or Erlang over Elixir?

JV: The use cases are pretty much similar. Since Elixir can interact with Erlang and vice-versa, with no performance cost or no bridging, they can be used interchangeably. The big win here is making the Erlang VM polyglot and allowing developers to choose the tools they are most comfortable with.

EI: So is migration from an Erlang app to Elixir something a developer should worry about, and if so, how should it be approached?

JV: They can also be used interchangeably in the same project! You can either install something like rebar_elixir_plugin and start adding Elixir into your tool chain or migrate your application to Mix, which is Elixir build tool.

It is very common, both in Elixir and Erlang, to build your project into many applications, where you have a parent umbrella project and all the children are in the apps directory. We have also heard reports of people using this style of development and mixing both languages with success.

If in doubt, join our mailing list or #elixir-lang on IRC and we will be glad to help you! 

EI: Psychology has a large effect on a programmer's perception and the uptake of a language. How might coming from Erlang and Ruby affect Elixir adoption, given that Erlang and Ruby have pretty opinionated communities surrounding them?

JV: When you are learning another programming language, you need to expect it is going to value different things than what your current language does. If you don't approach it with such expectations, all you get is a knee-jerk reaction instead of rationally thinking about the trade-offs. Of course, at the end of the day, some Ruby developers may conclude that multi-process concurrency will be enough for their use cases in the next couple years or some Erlang developers decide that a language that has not reached 1.0 yet is too soon for change, and that is fine.

That said, developers studying and adopting Elixir have been mostly successful, which is expected since, at this point, most of them are early adopters.

EI: I think that's a great point, that it should be expected that each advantage has its disadvantage, that certain aspects are prioritized differently in different languages.

Moving on to macros -- macros are one of the sources of Lisp's legendary power, and some have called it too powerful for the day-to-day work of regular programmers. Do you think there is any merit to this?

JV: Macros definitely give developers a lot of power and that is exactly why they are not a day-to-day resource. They are a last-resource tool. You should resort to macros when all the other abstractions provided by the language fails to solve the problem at hand. And even when you need to write a macro, the macro should do as little work as possible, often delegating to a function.

So educating developers about proper use of macros is definitely one of the concerns we have. I have been reviewing two of the books coming about Elixir (Programming Elixir and Introducing Elixir) and I asked both authors to leave similar warnings when introducing macros. After all, the first rule of the macro club is: "don't use macros!"

The language also goes a long way to ensure macros are self-contained. One of them is hygiene that ensures a macro won't pollute variables in the user namespace. Also, we limited the macro system to quote and unquote (there is no quasi-quote) and those operations don't have shortcuts. You need to be explicit and type quote and unquote.

EI: Are you planning on having any embedded way of writing and running unit tests with Elixir? What's next for the Mix rad?

JV: We believe Elixir is extensible enough for developers to try such features without a need to bake them into the language. So even though I have no plans, anyone can go for it! In general, my particular philosophy for tests is that you shouldn't test your private functions directly because this usually lead to tests too coupled to the implementation.

Regarding Mix, we are luckily going into the direction where tools are getting more and more stable, so I am happy to say there isn't much planned for mix except improving what we provide today.

EI: What would you consider a desired or complete ecosystem and tooling for the Elixir dev environment?

JV: That will depend a lot on which kind of applications you want to build. The things that are absolutely essential were baked into the language: interactive elixir (IEx), a test framework (ExUnit) and a build tool (Mix). For my company Plataformatec to use Elixir in production, we need proper web-related tools and we have been working on that on the side too. 

EI: And what do you see in the near future for Elixir?

JV: This is a very interesting question because, at this point, I figure I have the next 2 years of Elixir development already sketched. Looking at our own community and what other functional languages are tackling, there are common issues we will have to eventually tackle, like how to better handle nested data structures and proper date and time abstractions.

But we are not in a hurry. The short-term goal is to build better logging into the language, continue refining our current tools and integrate with Erlang R17 once it is out. Then get 1.0 out.

EI: Well we're looking forward to it! Thank you so much for taking the time to talk with us.

JV: My pleasure!

Leave a comment