Hello! CodeMesh 2013 is coming and if you are planning to attend this wonderful event you may have the chance of learning more about Elixir from his creator: José Valim. For those of you who will not be able to be in London the 4th, 5th December I prepared this interview to José. In the interview we talked about Elixir, its roots in the Erlang VM and the future of this newborn language. Enjoy! 😀
Elixir of life
Paolo – Hello José! It is a great thing to have you here in my blog for an interview. Would you like to introduce yourself in few words?
José – Hello Paolo! In few words, I am co-founder of Plataformatec, a consultancy based in Brazil and the creator of the Elixir programming language!
Paolo – José, you were previously known for you work in the Ruby on Rails Core Team. What was you experience with Erlang before writing Elixir? Why did you decide to write a new language and for what reason did
you choose the Erlang VM?
José – Before writing Elixir, I already had a good knowledge of the Erlang language and the Erlang VM. At the time, I was unhappy with the tools available to solve the concurrency issues in the Ruby ecosystem and the fantastic Seven Languages in Seven Weeks book helped me lay out the options out there. After reading the book, it solidified my opinion that the Erlang VM is one of the best environments to build and deploy robust concurrent software (my goals at the time).
After digging deeper into the Erlang language, I missed some of the flexibility and constructs that I find important in my toolbox, like meta-programming and polymorphism, as well as a better unicode support and other things, which led me to write Elixir.
Paolo – Elixir is based on the Erlang VM but has a syntax close to Ruby: for what reasons an Erlang developer should learn Elixir? What about Ruby developers?
José – Erlang developers know quite well syntax is often one of the first things that come up when discussing a new language. So while the syntax is similar to Ruby, the semantics are mostly from the Erlang VM. So leaving syntax out, an Erlang developer would find appeal in Elixir if he/she misses the same tools I missed when I started it. For example, we provide a macro system which gives developers the ability to meta-program, i.e. to write code that generates code. Another example is polymorphism, where Elixir provides something called protocols, heavily inspired by Clojure’s protocols, which allows developers to provide well-defined extension points in their libraries.
It is hard to explain such features in broad terms, so let me try to give some examples. Erlang developers are familiar with typespecs. In Elixir, we also have typespecs, except they were all implemented in Elixir itself using macros. There is no language extension because macros give users the ability to access and modify existing code. Another good example of macros is how we embed the unicode database into Elixir, at compilation time, which allows us to speed up many Elixir string operations by avoiding work at runtime.
Elixir also aims to provide a tidier standard library. For example, we provide an Enum module that is able to enumerate (i.e. map, fold, take, etc) all the collections in the language and such module is powered by protocols: Elixir knows how to enumerate your collection as long as you implement a protocol. After all, it is preferable to have a small set of functions that work well with a handful of collections than a completely different set of APIs for each data structure.
For any other developer, be a Ruby, Java, Python or Javascript programmer, learning Elixir means learning the semantics in the Erlang VM and all the amazing tooling existent for building robust, concurrent, fault-tolerant applications and that is more than enough reason for giving it a go.
Paolo – I have read the enthusiastic blog post “A week with Elixir” by Joe Armstrong. I also know that you are giving several talks around the world about Elixir. What kind of feedback do you receive from the Erlang community?
José – In general the feedback is quite good as the community agrees that the power lies on the Erlang VM and, while Elixir offers a slightly different perspective on it, the more developers using the Erlang VM translates into more knowledge, tools and enthusiasm in the ecosystem altogether.
Paolo – Some of our readers maybe want to contribute to some open source project based on Elixir. Do you want to suggest some projects in particular?
José – The community is still very young so the best suggestion right now is to try to solve a problem and see if there are any tools available and, if not, wright your own! We see some efforts converging though, we already have an “official” monad library, another for talking to postgresql, other to work with data and time, and so on.
Also I want to point out that Elixir is mostly written in Elixir, with the exception of a dozen of macros that we call “special forms”. This makes it very easy to contribute to Elixir itself, once you start learning the language!
Paolo – The 4th and 5th December you will give a talk at Code Mesh 2013. The talk title is: “Ecto: A language integrated query for Elixir”. Can you give to our readers some insights on you talk?
José – Besides the keynote about programming and Elixir, which I will give with Dave Thomas, I will also talk about Ecto.
In a nutshell, Ecto is a language integrated query to talk to relational databases in Elixir, heavily inspired by LINQ (from .NET). The goal of the talk is to introduce Ecto but, more importantly, also show how features provided by Elixir made the implementation of Ecto in the first place!
Paolo – Looking at the future: what should we expect from the new Elixir releases? In which part of the language will you focus the most?
José – In the short-term, we want to integrate with maps (when Erlang R17 comes out) while we work on a solid logging system to be shipped with the language, that builds on Erlang’s logger. Once that is done, we will release Elixir v1.0.
After Elixir v1.0 is out, we have many options to explore and the interesting thing is that we can explore those outside of the language, because macros give us all support we need. Some plans include providing better comprehensions, improving how we work with nested data structures, support to discriminated unions and more!