loading...

Ruby vs Elixir

ben profile image Ben Halpern ・1 min read

Software vs Software (10 Part Series)

1) React vs Vue: Compare and Contrast 2) AWS vs Azure vs Google Cloud 3 ... 8 3) VSCode vs Vim 4) PostgreSQL vs MongoDB 5) OOP vs Functional Programming 6) Computer Science vs Software Engineering 7) Python vs Java 8) Classical CSS vs CSS in JavaScript 9) Ruby vs Elixir 10) Imperative vs Declarative Programming

Ruby and Elixir are clearly very different languages, but they share a lot of community dynamics and principles.

Let's compare and contrast the details of each language and the contexts surrounding each.

I also want to take this moment to plug our latest DevDiscuss podcast episode, which was a really fun conversation diving into Ruby's place in the world.

play pause DevDiscuss

Discussion

markdown guide
 

Ruby: The one I miss. Elixir: the one I wish I knew.

Damn you JS, damn you!

 

Same but explained : I loved my time in Ruby on Rails and I have been trying really hard to find back some code quality I had in Ruby. I even tried Opale for JS. The thing is, both my work and personnal projects will involve quite some JS and not that many people know the language…

In theory, I have nothing but love for Elixir. In a perfect world, I choose to be an Elixir master every day. But time is lacking, the chance that it remains niche are high… I can't afford to write programs just for myself.

 
 
 

I am a fan of Elixir even though I wrote zero lines of it beyond a hello world example.

Erlang is the first massively parallel language I came across with and it resonated a lot. I liked it so much that once I even started exploring ways to use it side by side with Python and succeeded (though without an actual practical use case). The Erlang movie is also the first time my head exploded in regard of concurrency.

Thanks to Joe Armstrong's book on Erlang my skills as a developer definitely improved, even though I never worked with Erlang professionaly. Thus, regardless of popular adoption, I am a secret fan of both Erlang and Elixir.

Ruby vs Elixir it's a bit of an unfair comparison as Elixir (though it has a kinship with Ruby) sits on top of an actual platform (OTP), with a VM (BEAM) which is profoundly different from Ruby's. It is designed around the concept that a process will crash and worst case scenario you'll just restart that process and the life of your distributed system "goes on". Let's not forget that WhatsApp runs on this platform :-D

OTP is a platform made to write fault tolerant parallel programs, it has simple primitives/functions allowing a developer to create a cluster of linked processes sharing no state (within the VM, not OS processes) with minimal footprint, organize them in trees of processes and have either monitoring processes attached to them or (this is where my head exploded at the time) even upgrade them with no downtime by hot swapping distributed code using versioning. It also comes prepackaged with a real time and distributed DB called Mnesia, which of course can be used via Elixir, though I'm not sure how popular that is.

When I think of OTP I think of concurrency made really well.

Ruby fits a much more popular concurrency model (run OS processes or run OS threads, fibers aside) and doesn't discourage people from creating a single process imperative program. I'm not sure if with Elixir is the same but spawning a process and linking it with another and send messages to it, is at the beginning of every Erlang tutorial :D

Elixir requires a developer to understand pattern matching, head/tail list manipulation, imperative and functional programming, a bit of declarative programming too, macros and other things.

Though many Rubysts are also Elixir programmers or have switched I think the amount of things to learn is a bit more.

Historically Elixir also suffered a bit because for the longest time the most popular cloud platforms were not supporting it natively.

 

As mentioned, the most amazing thing about Ruby is the community, and especially the Gem ecosystem.

Like, ok. JS has a huge community with NPM packages for everything. Cool; whatever. There's so many of them for even the same purpose that you get some sort of like package fatigue. Seriously, have you seen how many React state management libraries there are? Or how many different Webpack alternatives? Or how many different Fetch alternatives?

In the Ruby ecosystem, you have more or less one Gem for everything, and the Gems are usually very well supported and battle tested in big companies.

Of course, there's a lot of great, well-known & battle tested NPM libraries as well... but I find RubyGems to be easier to navigate as well as more focused.

 

My opinion below comes from 2 years of trying to build something powerful and secure with elixir.

Phoenix absinthe doesn't have documentation that can compare to laravel or express.

Also, the website that runs the forum works on ruby on rails, the courses are scarce, to say the least.

People that are blogging about elixir, have their websites built-in WordPress or something else rather than elixir frameworks.

What can change this situation?

Simple: A community effort to make the language accessible and productive to everybody, with clear best practices and a solid auth solution that respects the latest specs.

Graphql should be taken seriously because it offers great freedom and with some improvements regarding security it can most definitely bring very clear API's.

Final thoughts:

JWT is old, there is a better solution

Graphql is here to stay

Liveview is not a solution if you really want to make something interactive following a user story.

Thanks for reading

 

just the reaso why I never built anything i it. I was lookig for fast an easy generators. Neither laravel, express, or phoenix offers it. WordPress or other cms, or in my case JHipster, still were much easier to build in.

However JWT is not old, but it depends on what do you consider old, 5 years, 10 years, number of tech after that. There might be better solutions in some cases but I really don't see one for inter service communication. If you aim for OIDC/OAuth they both still use JWT so I would like to hear what's the actual better solution, why? Mainly as I'm seeking out good solutions myself

 

Hi @haricsecic

JWT is old from a security's point of view because it doesn't respect the latest specs and can be easily highjacked.

Randall Degges has a great talk on this here youtube.com/watch?v=Ai7PVLl4Wng

Thanks I'll check it out. I'm aware of some issues but I'm asking about alternatives and what would be as easy to use in API to API scenario, not browser to API

I don't use Api's, I use graphql because it creates a real user experience with great feedback.

Laravel is great once you understand what you can do with it.

GraphQL is API. Backend services have no user experience when communicating with each other as the gateway or whatever is the one exposed to frontend. I think you lack some knowledge in this field to understand the question and why JWT is not so bad as one might think.

First of all graphql creates a great api that combined with a ssr framework on the frontend creates a great user experience and can serve many clients, from mobile to OS. if you know what stacks to use.

JWT has big security problems, I would use a http cookie any day over jwt.

I already assumed that you know that graphql will be used with a frontend and i don't have to mention that.

As said you lack some knowledge here. Cookies can also be hijacked. Http cookies contain JWT itself sometimes. The thing you want to complain about is local storage which was prooven to have quite same security as cookies since there's other ways to exploit them.

Why are you saying "you don't use api but graphql" and once I pointed out "that graphql is in fact api" you go explaining it like I'm saying something bad about it? I'm pointing out that I have background services communicating with each other without any user doing anything. You'll need to work with much more complex system to understand my point. You can have graphql calling other services including other grpahql or other types of API where you're sending jwt between them and user has no direct communication with these ones. Point is graphql has nothing to do with the things I'm talking about.

 

I suspect Ruby is an inspiration for Elixer. When I was coding Ruby and following community guidelines for solid OOP it forced/allowed me to stick to:

  • "one responsibility per class"
  • "tests that are not tightly coupled to your code"
  • D.R.Y
  • "preemptive isolation"
  • "public/private interfaces"
  • L.O.D.
  • "Duck Types"
  • Polymorphism
  • Inheiritance

Elixer has metaprogramming so ... maybe there many things in common? Not sure.

REF: Sandi Metz's book Practical Object-Oriented Design in Ruby , an oldie but a goody

 

I suspect Ruby is an inspiration for Elixir.

José Valim and his folks from Plataformatec, the ones behind Elixir, were actually well known Ruby developers. They were also the guys behind Devise, one of the most used/battle-tested Ruby gems.

So yeah, you cant take it as a fact that there was an inspiration :)

 

I already wrote about it at length in 2017, I guess all is left is to paste a link, because my opinion did not change much: katafrakt.me/2017/03/28/ruby-vs-el...

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.

 

Came here to learn and if Phonenix doesn't have as nice CRUD as RoR I'm glad that I haven't worked with it yet. I needed fast generator for both front and back and quick to modify an throw away. Still JHipster on damn Java looked easier. Thought it was me because I'm used to something but no. It's apparently tiny pieces missing in each of these so they can be easy to prototype with while generating UI and backend crud.

 

I highly recommend watching this about Elixir:

 
 

Ruby is an awesome language, pretty simple to learn and fun to master. What makes Ruby more fun is RoR, although I had no real-world experience with RoR but tried it a few times and the experience was pleasant. But there is BUT, Ruby is very slow not very much suitable for many situations, I wish Ruby was faster then it would have been my primary programming language. On the other hand, Elixir is one of the most perfect languages I've ever seen, for real. Elixir also shares some coding style like "do" and "end" with Ruby and that's what gives me the feeling of working with Ruby which I love it. Elixir is very fast, the Phoenix framework usually responses in microseconds instead of milliseconds. And learning an FP language like Elixir is an awesome experience.

 

I love Ruby. I was a fanboy for a decade - using it for most of my projects, professional and personal. it was great.
Then I tried Elixir and for the last 5 years I haven't touched Ruby again. Elixir has everything that makes coding so much fun in Ruby, and then some. I'm really trying to think of a reason to use Ruby on a new project, and i just can't. Elixir does everything I care about better. I'm not hating on Ruby. It really is great. Elixir is just more so.

 

What is absolutely right is the lack of up-to-date tutorials for Elixir, especially for Phoenix. I tried some of them: at Pluralsight - outdated neither the author nor Pluralsight do absolutely nothing to point it out or change the current situation! I've read both books by Pragmatic Programmers: Programming Phoenix 1.4 (pragprog.com/titles/phoenix14/), (the actual version is 1.5.3), and Programming Elixir 1.6 (pragprog.com/titles/elixir16/), as well as Phoenix for Rails Developers by Elvio Vicosa, followed the best tutorial by Dave Thomas (codestool.coding-gnome.com/courses...), and still stuck very often when developing a web app or just a single module in Elixir. It feels unusual compared to Ruby/Ruby on Rails situation, when after just reading both books on Ruby Language and Agile Web Development with Rails [3, 4, 5, 6], you are almost done to start-up, backed up with a huge gem ecosystem and community support. Sure, Elixir and Phoenix do also have Slack channels and forums, but you will have to weight it twice before choosing between Elixir/Phoenix and Ruby/Rails.

 

Ruby is an OOP language, Elixir is functional. I find it much easier to test and reason about a functional app (and I work on two Phoenix apps and one legacy Rails app at $work).

On top of that Elixir (and most library) documentation is first-class, and the core team is super responsive to doc PRs. The Elixir community is helpful and welcoming. I would strongly encourage people to take a test-drive and make up their own minds.

Oh, and if nothing else, I see lots of references to Rails shops actively converting to Elixir/Phoenix. 😀

 

I like both, I learned Elixir first. Very cool, like the functional approach. A year later, I try some little things in ruby in order to understand why it's so popular and I get it. Syntax in nice and clear. If I have to go for a web dev project, Elixir, because Phoenix and Ecto are just to pleasant to use.

 

I love both and made pretty "big" things on both, but I take more liking on elixir, because it does scale better on the same hardware, but as languages, hey, Elixir takes all the love from Ruby so I don't see a versus here :-p

 
 

One day I definitely sit and write something with Elixir and Phoenix. Those are one of my priority technologies to learn.

 

Ruby should 100% be a thing