Elixir vs Ruby - where to use?

Iren Korkishko on May 10, 2018

Originally I posted this material on Syndicode blog. Updated. I work in a Ruby on Rails agency, and we choose Ruby as our main programming langua... [Read Full]
markdown guide

(Ruby developer here)

I don't really see how Ruby is more fit for prototypes, MVPs and "fast and secure web or mobile apps". Of course, other than having experienced Ruby developers and not having Elixir developers. Which is Netguru's case but is really, really far from truth.

Also, putting functional paradigm as a con for Elixir seems like a joke. It's a different paradigm, not worse paradigm. Again, if you have your software house full of Ruby devs, that might be true for your business, but is not true in general.


Thank you, Paweł!
That's really nice to hear from Ruby developer!

Of course, functional paradigm is not worse! It's just different, as you say, and it's obvious. And, yes, Elixir is really awesome. But it's a niche language still (despite it is as approachable as Ruby). I guess, we just need more time for Elixir to become as spread as Ruby. And I followed Netguru's example by putting functional paradigm to cons only because it's harder to find these developers (I mean experienced ones and not only newbies who were recently attracted by Elixir). That will slow your production and make you switch back to object-oriented languages. So that really makes sense in this case.
I can name at least two reasons why Ruby is better for prototypes:

  1. The Elixir community is too small comparing to Ruby community. When you need some awesome functionality, you can easily take it from available examples with Ruby. With Elixir you should develop it from scratch. And that is an additional time you can't afford when making a prototype.
  2. The number of libraries in Elixir is smaller than in Ruby. This reason is very similar to the first one but should be mentioned. Still, this factor affects the same things when we talk about fast development and functionality.

Prototyping with Ruby really works better. Simply because it's fast.

That was my opinion based on some general factors. But I really liked your comment! Thanks for that!
Moreover, I really believe that in future Elixir will engage more talented developers.


What do you say about the fact that Elixir is less strongly typed than Erlang, which makes it a step backwards?

Thank you for the comment, Mihail! Maybe, Elixir is less strongly typed that Erland, but Erlang was built to run cell networks... And these days how often cell networks are down? So a 'step backward' is a controversial statement as it really depends on the case of use. Every language was made to meet some expectations and to be used for some tasks.
Elixir comes with its own version of the standard library, which means you get a more predictable API, while still being able to use all of Erlang's standard library. Also, if you're coming from a high-level language, Elixir might feel more approachable and less dense than Erlang.
On the other hand, if you want very terse syntax and configuration over convention, Erlang is a better choice.
Elixir has a metaprogramming (macro) system that gets rid of a lot of boilerplate, and a lot of people think that Elixir is nicer to write than Erlang.
To conclude, Elixir makes the Erlang ecosystem accessible to web developers. It helps reduce the barrier of entry to an ecosystem that addresses scaling and performance concerns for getting your app to handle lots of connections.

I am not sure what your perception of cell networks is.

If you think they are reliable and hardly ever down:

Well yeah, they were written in strongly typed Erlang.

If you think they are unreliable and commonly down:

Some hipsters must have snuck in some Elixir, or other other languages in.

It's easy to work backwards from a conclusion about a system we both know very little about.


I would put my own [very biased] opinion in a single sentence: since we partially moved to Elixir in production, every single hour I need to deal with Ruby code is a nightmare.

Even for MVP and prototypes I always pick up Elixir. In general, once one gets the taste of stateless programming, the mutability of any kind just becomes a pure disaster.


Thank you for the comment, Aleksei! It's interesting to hear these thoughts! Recently I also found an opinion of a Ruby developer who tried Elixir syndicode.com/2018/06/21/elixir-fr...
I think that in a few years there will be more developers interested in FP. Let's see how these will evolve with software development companies!


And, finally, the Elixir’s style of programming is similar to how I like to write Ruby.

Uhoh. That is literally scary.


(...) every single hour I need to deal with Ruby code is a nightmare.

Well, perhaps you're not surrounded by great Ruby developers or it's just a matter of your personal taste.

I've been writing Ruby code for 7 years and Elixir for almost 4 years, and I can do tell that it is a great pleasure to maintain well written Ruby code. Its expressiveness and productivity are still near unbeatable.

(...) the mutability of any kind just becomes a pure disaster

Immutability is awesome for writing safe concurrent software but it's important to keep in mind that it's not a panacea. In general when you're dealing with complex objects/data structures on heavy computation, then working with mutable data is much faster and more cost-effective just because you are not copying tons of bytes on every change made. Game development is a good example in regards to that.

At the end of the day we are getting paid for solving business problems. So if Ruby fits the non-functional requirements, even not being the most efficient tool out there, I would pick it. For some special cases where high concurrency (by this I mean thousands of requests per second) is expected from day one, then Elixir is the first thing that comes up to mind.


This is a really great exploration of the relative advantages, thanks! I'm going to refer to this the next time I think Elixir would be a good fit for a project.

I love Elixir, but when I suggest it for projects people always ask "Why not Ruby?" The community and supporting projects in the Ruby ecosystem is just so many years ahead of Elixirs', and there are also so many uncommon common concepts to learn in Elixir.

The concepts I see people struggle with are some of Elixir's greatest strengths, so I think when developers become more comfortable with the language and the motivation behind its design, many of its perceived disadvantages will become advantages, like these:

  • no for loops -- this isn't an advantage by itself, but I think it is a good decision to encourage more use of recursion
  • function dispatch based on pattern matching -- there's nothing like it in other languages, but it encourages smaller functions with less complex conditionals
  • managing concurrency, state, and errors using GenServer -- there are so many concepts to put together for this, but it's a rare example of a truly reliable and fully encapsulated abstraction (unlike leaky objects)

You listed "smaller ecosystem" as a con for Elixir, but I think it can be a pro also. I couldn't find an Elixir-y SQLite client library so I built one and it ended up getting a bunch of downloads. Having a smaller but growing community makes it feel more fun and full of opportunity to me. For example I love Python too, but to make a real contribution to that ecosystem (like Ruby's) I couldn't just write an SQLite library.


Hi, Eli! Thanks for your comment! That all really make sense and I agree with you. Sometimes we just use stereotypes to consider something to be pros or cons. In this case, a smaller ecosystem can really be a great thing from that point that every single developer can contribute and make an impact. I hope that your SQLite library will attract more attention and users! Good luck to you!


no for loops -- this isn't an advantage by itself, but I think it is a good decision to encourage more use of recursion

Recursion is not what you want to encourage.

List comprehensions and Stream combinators, where the iteration pattern is abstracted away, are what you should be encouraging. They're way more readable than recursive functions.


Actually there is for & foreach loop

for n <- 1..100 do

This for loop uses shadowing.


reading well-written Ruby code is a pleasure

This may be an unpopular opinion, but I really don’t like the syntax of Ruby. I’ll be completely honest, it was one of my biggest turn aways from the language


I review quite a lot or Ruby code every day, and good Ruby code reads really well. If you pair this with all the conventions that Rails developers share, there's a point where you can read code at almost the same speed you would read it if it was pseudocode.


Thank you for the comment! We all different, so every opinion here matters for me!


Ruby is laconic, the code is easy-readable, you 'write what you mean' and you can understand what you read. And I like that part.


I use Elixir pretty much anywhere I can get away with it. Ruby has a few too many warts for me and I've grown tired of it. Elixir just eliminates so much boilerplate and pattern matching makes for smaller, more testable functions. Less stress for me, more time for the family!


Thank you for the comment, Sergio! That is great to hear! I think many people will think more of Elixir if they know such benefits.


I don't really see a "vs" between those 2 languages. After all, José Valim was a Ruby developer (and book author) before he developed Elixir. Its syntax is almost identical to Ruby and even Phoenix feels a lot like Rails.

Looking at your pro and con arguments - I agree that Ruby is better for prototypes & MVPs, because of the number of libraries and the big eco system. But I think you shouldn't count the functional programming as a con for Elixir. IMHO it is a pro argument when looking at it for its own. Sure, you will probably find fewer developers that know functional programming in general or Elixir in particular, but that is an indirect consequence you shouldn't attribute to functional programming.

In my opinion Elixir/Phoenix is the nearest step to go as a Ruby/Rails developer when you're looking for more performance, a more distributed system, or just more functional programming.


Thank you for your comment! Yes, you’re absolutely write! I already agreed with other devs that I really shouldn’t consider functional programming paradigm as a con.
So in the article updates I will make some changes according to what you and others suggested!


I don't really see a "vs" between those 2 languages. After all, José Valim was a Ruby developer (and book author) before he developed Elixir. Its syntax is almost identical to Ruby and even Phoenix feels a lot like Rails.

That's exactly what makes it a vs comparison. Elixir was built based on José's experience with maintaining and consulting on Ruby apps, with the explicit intent of fixing the warts and inefficiencies that they kept having to work around.


I've tried Elixir in the past and it's just been frustrating. Many things about the language just fail to remember the human who is writing the code. Ruby is really a stress reliever to write and it's easier to get the desired result. Just my opinions though. I know many happy Elixir developers as well. Rails tends to be memory heavy, Elixir wins on concurrency but at the cost of developer happiness.


I don’t think your argument that Ruby has a more robust ecosystem holds water. After all, you not only have all of Hex.pm and other Elixir packages at your disposal, you also have every Erlang module at your fingertips too.



Thank you, Christopher! That might be a good point!


I'm not sure where you got that Elixir's purpose is a "fast language", but the official website says it was "designed for building scalable and maintainable applications".


Yes, the formulation I put was not very correct. I guess I would change it to 'concurrent language' as far as José Valim meant to create something scalable and performant.
Thank you!
Will update!


IMHO, elixir has the same purpose of ruby's: developer happiness.

But the implementation takes many forms: test and compilation run in parallel using all cores so it's as fast as possible, command-line easiness to setup and generate code, easy and readable syntax with (not too much) macros and standard lib.

The purpose is evident in the latest (and coming) versions of the language: formatter, property-based testing and standard releases, which are features to make the developer's life easier to focus on what he wants to achieve.

But then again, it's hard tu summarise in a sentence, so I'm not necessarily nitpicking :)


Thank you very much for this comment, Aleksandra!

code of conduct - report abuse