Ruby vs. Elixir (post-wroc_love.rb 2017)

One of the most anticipated event at past wroc_love.rb conference was Ruby vs. Elixir panel. Quite a few blog post were written about it, but as one of main criticisers, I decided to add mine too. Also, I’m going to give a perspective of a person, who knew Ruby and Erlang (to some extent) long before Elixir was born.

First of all, I want to state clearly that in my opinion “Ruby vs. Elixir” is a false dilemma. It’s not like they compete on the same field, so they have “fight to death” over various resources, such as programming manpower, wide adoption, technology support because of popularity etc. Instead, they try to fit in different aspects of tech. Or to put it in Hubert Łępicki’s words: they make different kind of promises.

That being said, I’d like to go back to the question that was actually mine and opened aforementioned panel:

Why Elixir is “sold” to us as “new better Ruby” while its underlying principles are totally different? Won’t it result in Elixir programmers that do not understand Elixir (like Rails programmers that do not know Ruby)?

I think that the question was a bit misunderstood. Its goal was to underline what I think the main problem of Elixir, Ruby and such debates is. And to name it: it’s all the Elixir preachers and neophytes, who don’t really get it (do they?).

There is literally tons of blog posts titled something like “Going from Ruby to Elixir” or “From Rails to Phoenix”. They sound like it’s basically the same, but newer, more hipster and sugar-coated with this shiny functional paradigm that becomes more and more popular lately.

They couldn’t be more wrong.

Yes, Elixir’s syntax is very similar to Ruby. Yes, Phoenix is here and there inspired by concepts that were battle-proven by Rails. Yes, Jose was Ruby developer once. But that’s more or less it. Elixir is not Ruby with immutability which is supposed to solve everything and fancy pipe operator. It is different language with different design goals, largely enforced by BEAM, which it targets.

Elixir, like Erlang, is all about actors, message-passing, pattern-matching and data transformations. They are baked right into the language and if you are not using them, don’t understand them, you’re missing out. And you won’t (use/understand) if you are expecting to have this “new shiny Ruby”.

As for comparison to Rails in my question: I did quite a few tech interviews for Ruby positions during past few years. Too many times I have seen apt “Rails programmers” who didn’t really know Ruby. As an example, maybe one person was able to answer what Global Interpreter Lock is. And exactly one could tell me anything about eigenclasses. This is what Rails did to us: detached from understanding underlying principles of language it’s written in. And I’m seriously afraid that the naïve evangelism some people are practicing will do the same to Elixir.

Creating the dichotomy certainly does not help here, either. It’s not like: Ruby or Elixir - take what you want because it’s just a matter of taste. It is about choosing right tool for the job. Rails-powered CRUD-based web applications would probably never be threatened by Phoenix. Elixir doesn’t have magic gems system or anything as convenient in simple cases as ActiveRecord. It’s designed for different purposes.

What is in danger, then? Certainly apps with heavy load with a lot of requests. Or lots of websocket connections, as they don’t scale well horizontally. But both cases are not the ones where Rails (or any Ruby framework, to be honest) is a good fit. It’s natural that sooner or later something would drive Ruby away from those applications. And believe me, it’s much better to have Elixir there than node.js. But that’s a different story…

So to sum up:

• Don’t be a neophyte-preacher. Don’t tell people what is not true: that they can replace Ruby with Elixir.
• Learn Elixir as a new language, not as a foreign dialect of Ruby. You’ll see where it fits by yourself.
• Don’t engage in tribal wars. Ruby and Elixir are not direct competitors. Concentrate what each can learn from one another, to make both ecosystems better.

What else to read

• Michał Muskała: Why I stayed with Elixir
• Maciek Talaska: Wrocloverb 2017: Elixir vs Ruby - unanswered questions