Elixir vs Ruby on Rails

I don’t really know how to frame this because I’ve never used Ruby, or Rails, or even looked much into them. I have been avidly working with Elixir these last couple months, and was exposed to it some time last year. So this question comes from complete ignorance of any of the Ruby world.

To my understanding, Elixir is to Ruby as Phoenix is to Ruby on Rails. Is this assessment correct?

The reason why I ask is because in my company there is an interest in Erlang/OTP but no interest in Elixir because Elixir == Rails. From my time in Elixir and my reading, that does not seem correct. However, I want to provide accurate information. When I look at comparisons, pages come up doing comparisons according to my original assessment. I don’t understand the disdain for RoR, but in the applications I’ve been working on, Elixir has been an incredible language and I want to show that Elixir is worthy of consideration (though there really wouldn’t be anything wrong per-se going with raw Erlang)…so in relation to all this, is there a reason why someone who would dislike RoR also dislike Elixir? Syntax aside, since apparently Elixir has a lot of Ruby syntax influence.

That is essentially correct, although Phoenix is a lot less of a monolithic framework than rails.

This is definitely wrong. Elixir is a programming language, not a web framework. It doesn’t contain a web framework at all.

I think it’s just the syntax. People see Elixir’s syntax, they see the Ruby influence, and they jump to the conclusion that Elixir “Rubified” Erlang. This is simply not true. Elixir is a function language with immutable data and 0 overhead with respect to the equivalent Erlang, equivalent code compiles to equivalent byte code.

14 Likes

This is all exactly what I thought. Is there some sort of sharable article? My search-engine-foo is not producing results

1 Like

This is probably the best short presentation for explaining the ecosystem: https://www.youtube.com/watch?v=JvBT4XBdoUE - Phoenix is used to provide an easy way to interact with the system, but I would be surprised if your colleagues are still equating Elixir with Rails after watching this

10 Likes

Saša is awesome. He’s one of the reasons why I was excited to learn Elixir (that video included) :slight_smile: thanks for bringing it up

4 Likes

Yep - I don’t watch many movies more than once, but I’ve watched this talk a few times!

4 Likes

Consequently, I was watching this (again) today. I would also recommend the first three paragraphs of the preface of Elixir in Action, also by Saša Jurić.

If someone says this, the problem is psychological, not technical. They are labeling something to deliberately attach some known bad connotations and they are priming others to feel bad upfront – and likely be driven by confirmation bias when looking into it.

This is most likely deliberate, because people generally hate changes of status quo. It’s rather natural defensive mechanism, doesn’t necessarily mean that they are “bad people”.

Try to go via their ego, carefully indirectly question their ability to apply critical thinking on this… Make sure not to attack anyone directly. Raise a rhetorical question “I wonder if we have anyone in the team that would be able to filter out all our biases and perform independent analysis…”. You plant a bug and some folks will step up :slight_smile:

4 Likes

what makes phoenix a lot less monolithic framework than rails? Genuinenly curious :slight_smile:

Well, actually there is httpd in OTP.

Rails is framework that is actually built from few libraries:

  • ActiveSupport
  • ActiveModel and ActiveRecord
  • ActionView
  • ActionPack

Other parts are helper modules for different aspects and do not really need to be included. In fact even ActiveModel and ActiveRecord aren’t really required parts.

So there is few tightly connected libraries that cannot live without each other (especially almost everything rely on ActiveSupport).

On the other hand Phoenix is just a helper library for Plug with few macros for simpler routing definitions and sockets handling, other than that there is really nothing “big” in it. Even the storage layer - Ecto - is completely independent, and while there are some people working on both, the projects aren’t related to each other in any way. For example most controllers in phoenix can be simplified to:

defmodule MyApp.Controllers.Foo do
  @behaviour Plug

  @impl true
  def init(opts), do: opts

  @impl true
  def call(%Plug.Conn{params: params} = conn, _opts) do
    action = Phoenix.Controller.action_name(conn)
    apply(__MODULE__, action, [conn, params])
  end

  # … 
end

Of course it is very simplified as there is few more things like setting default layout and view or calling Plugs defined within the controller, but very simple version of controller can look like that and for Phoenix there will be no difference, as there in reality is no more magic.

13 Likes

This also means in most places you can easily mix and match between low level plugs and the a bit more high level code of a phoenix project.

6 Likes

As I’ve not seen this mentioned here yet, I would advise to buy/read the following book https://pragprog.com/book/tvmelixir/adopting-elixir it’s really helpful and gives a nice overview and ways of starting out with elixir(and/or phoenix) within companies.

I have extensive experience (in form of tech lead and hiring people for teams) with Ruby on Rails from the start (around 2005). Next to that I’m coding in Elixir for a couple of years now and with that I’m also using Phoenix quite a lot. Given Ruby and Elixir are the programming languages and Ruby on Rails and Phoenix are the web frameworks, the opinion I can give you is that RoR is almost its own language on top of Ruby. So saying you’re fluent in Ruby is not the same as being fluent in Ruby on Rails and the other way around as RoR is giving you so much ‘extra’ it is for most pure RoR devs hard to do ‘pure’ Ruby, without all the Rails helper parts. Next to that there’s also quite a lot of “convention over configuration” to learn with RoR. (aka the ways of the framework, sometimes called the ‘opinionated’ part). This on its own is definitely not super bad, it worked quite good for years and still works as long as you stick with the framework way of doing things. Often the negative/bad things where people talk about happen when you stray off this path and want to do other things which don’t fit the frameworks mold.

But this is quite the opposite of my experience with Elixir and Phoenix. Phoenix is for the most part ‘just’ elixir with not that much extras on top. Which is quite a nice experience. The more you start out with only phoenix you’ll see over time that most of the constructs are ‘just’ basic elixir. (Maybe only the router DSL falls out of this statement) But Elixir is quite a bit more harder to learn given the functional constructs (certainly if you’re used to/coming directly from ruby). The perspective is a lot more from the Data and mutating them with a couple of functions instead of making a lot of custom abstractions (OO classes) and adding custom functions to them. But when you’re finally there and have some code in it you’ll see that a lot of problems of Ruby code don’t show up in elixir. (most issues having to do with state which comes from everywhere) And those couple of functions that can mutate most data structures are then way easier to work with.

So for me there’s not really a reason to dislike Elixir/Phoenix if you dislike Ruby/Rails, but it all depends what the original reasons are. I think they also fill a different niche/use case better. And there’s even more than a use case, you also have to take into account the sentiment within an existing team. If you want to make a good decision it’s best to start out small with a perfect use case for the framework and just see if it works out for you (and your team).

Have fun coding! (doesn’t matter which language/framework!)

11 Likes

As someone who prefers Erlang to Elixir I can without a doubt say that their concerns are not valid. If they are interested in Erlang/OTP there is no reason not to consider Elixir, esp if they already have someone at the company who has been working with it.

From the outside looking in on both Rails and Phoenix I’ve seen there is concern about how Rails becomes essentially its own language to learn. Like a Ruby person can’t just jump into a Rails project and a Rails person can’t just jump into a Ruby project. I don’t know how true this is but I do know that it isn’t the case with Phoenix.

Sure, I think the Plug macro pipeline is confusing to read coming from Erlang but that’s about it – again very limited Phoenix exp and no Rails exp, so take this with a grain of salt.

That all said – Elixir/Phoenix is not like what happened with Ruby/Rails – definitely nothing wrong going with straight up Erlang :). Tooling and integration with Elixir projects has improved a lot. I saw someone mentioned Adopting Elixir so I’m obligated to mention Adopting Erlang booksite :slight_smile:

12 Likes

As someone who literally started elixir with plug as a substitute for Sinatra: Plug macro pipeline is confusing until you learn to read it, I’m still not really there after 3 years!!

But i have to say, it is a wonderful piece of tech.

I think part of it is the cognitive shift between module layout which is mostly position-independent (well not entirely, @ tributes are not), to something which is. Maybe some sort of warning or big loud shouty announcement in the docs would be useful?

@tristan @ityonemo Plug pipeline is quite simple conceptually, it is different way to write Enum.reduce_while/3:

conn = conn_from_req(request)

plugs_list
|> Enum.reduce_while(conn, fn {mod, opts}, conn ->
  case mod.call(conn, mod.init(opts)) do
    %Plug.Conn{halt: true} = next ->
      {:halt, next}
    %Plug.Conn{} = next ->
      {:cont, next}
  end
end)
|> resp_from_conn()
3 Likes

Yes, conceptually it’s easy, but being conceptually easy does not necessarily unconfusing, especially if there is a paradigm mismatch with the rest of the language. Imo, plug’s cognitive mismatch is slight enough that it lives a bit inside of the uncanny valley in terms of how you do it, even if it’s easy to understand (which I agree it is).

That said, I think its architecture was the right choice, but maybe there could be a better way to address the cognitive mismatches early on.

1 Like

As a Rails dev I don’t think there’s much of a difference here, expect perhaps in degree. Rails relies a lot on convention and to that extent what it’s doing might not be transparent to a Ruby dev, and conversely a Rails dev might never have to learn strong Ruby skills to produce a lot of small, simple Rails apps, but a competent Rails dev knows not only how to use Rails but how Rails itself works. That I don’t think is in principle different than Elixir/Phoenix (and I’m feeling it as a non-competent LiveView user right now), even if the latter is a bit more limited in scope and transparent about what it’s doing.

I’m going to guess that maybe you (or they) meant “Elixir == Ruby”, because Elixir transforms into Erlang, and Ruby is interpreted by YARV, which is written in C, so they’re both a more developer-friendly syntax on top of a lower-level language.

I’ve encountered some what I would call “old school” programmers who think anything not written in C++ or C is too slow or trying to do too much for you. They’re knock on Ruby is kind of legitimate, because even with the increased speed of YARV, it’s still kind of slow. And if the first thing your coworkers heard about Elixir is that it’s like Ruby for Erlang, maybe they just assumed it has all the same shortcomings.

If they actually did say “Elixir == Rails”, well then, as other commenters have pointed out, that makes absolutely no sense.

2 Likes

This sounds very much like a prejudice. Apart from the fact that, as others said, Elixir is a language and Rails is a framework, I can smell a hint of language snobbism in your colleagues’ assessment.

Of course there might be very valid reasons to choose not to use Elixir, but dismissing it completely because of a purported similitude with Rails or Ruby is in my opinion very superficial. Let alone the fact that both Ruby and Rails are used with great success by many companies, and while it’s totally ok to deem it unfit for a specific project, denigrating another tech in absolute terms does not add merit to one’s choice.

There seems to be a trend in some parts of the programming community, to promote own beliefs by spreading disdain for other languages or technologies. It sometimes borderlines with gatekeeping (e.g. “X is not for real programmers”), and I think it’s mostly a form of ego boosting.

While I think that it’s useful for a team to discuss pros and cons of different technologies in a given context, taking into consideration project requirements and team, I find absolute statements on demerits of other tech mostly a waste of energy.

If I am guessing right, the problem with your colleagues is not much about technical considerations, but about ego. You could try to lead by example, similar to what @josefrichter suggested, and gently but constantly advocate for a more open minded environment, where it is ok to argue technical points and decide for or against things, but there is no praise or ego boost in merely despising other technologies, languages, or practices.

4 Likes

Elixir is way faster than Ruby.

1 Like