Elixir vs Ruby on Rails

The only thing I’d add to this is that this kind of behaviour I’ve seen mostly from people who don’t actually know or understand the thing they use as a negative label - in this case Rails. Wouldn’t be much surprised if this was the case here too.

There has been good amount of people coming here after they’ve read severely misinformed blog articles (which have been thoroughly debunked shortly after they were written). The problem with this is like with TV series like “Ancient Aliens” – people just read/listen and believe everything that is being sent their way.

Phoenix is practically one of the smallest web frameworks I’ve ever seen and I programmed in 5 high-level languages for 10+ years. Really weird that somebody would conflate it with Elixir. They likely think that Phoenix is to Elixir like Rails is to Ruby – which is very far from the truth.

That’s just the thing. Even a Phoenix controller is pure Elixir – it’s just a module that follows a few conventions.

I believe this thread started going in circles though. Not sure we can say anything extra that would add to the facts that are already known?

I think so too. Only the fact that Elixir is faster than Ruby is on topic.

This should perhaps be moved to its own thread?

Might be worth writing a “No, Elixir is not like Ruby” blog post

In my conversations, the complaints have been around simply a hatred towards the design of Rails. An appreciation for Ruby, but Rails was like sour milk to them (not sure why, probably in the design). My colleagues are quite pragmatic about why they choose X or Y. So I wouldn’t say with them it’s about snobbery at all. I think there is blurred thinking between Phoenix and Elixir itself, and that’s where the problem is. If there was a time where they decided to hop languages and chose Erlang over Elixir, it would be no big deal, but I’d hope they’d take a fair look at Elixir without preconceptions of it. So, my code today likely is a good model, and also one reason why I chose not to build it with Phoenix. So that pure Elixir can be seen.

Not just harder, it often makes it impossible. How do you argue about old languages like Java producing programs 2 to 3 times slower on average than Rust (a language still in its infancy) equivalents? Surely Java, being waaay older and adopted by so many corporate behemoths, should have the advantage with its super optimised compilations backed by thousand of doctorate thesis. Something just doesn’t add up.

Yes.

No. It mean that language specification makes it harder to have efficient implementation, but nothing prevents you from writing x86 byte code interpreter in Elixir making x86 assembly at most as fast as Elixir.

This is accurate and it’s both a strength and weakness of Ruby. Ruby is a malleable language and Rails (at least early on, I don’t know if this has changed) actually modifies the language itself to make it friendlier for web development. Adding functions like .blank? to the root string object is a simple example so you can say " ".blank?.

On one hand, this is a super power. I can inject a function directly into the root String object and make it available everywhere (or change behavior everywhere) without having to fight the entire inheritance tree. This is especially valuable when dealing with 3rd party libraries, both for adding quick fixes without having to fork/branch the entire library while you wait for a PR to be approved…and for making 3rd party libraries easy to use because they can easily inject themselves at the appropriate places within your code base. It’s the closest thing to workable Aspect Oriented Programming I’ve ever encountered. When dealing with huge inheritance trees in OOP, the ability to fix something at level 3 without having to rework the entire hierarchy is awesome. There are, of course, many trade offs and negative consequences to it as well.

Elixir doesn’t do anything that you don’t tell it to do. It’s more explicit. The functional paradigm also entirely avoids the OOP hierarchy entanglement where such approaches are beneficial. When you don’t have to worry about a function call transforming a value that you can’t see, hidden within a stateful object, the functional approach simplifies explicitly calling everything and leads to much easier long term maintenance.

Languages features have implications on their implementations speeds. It follows that languages do have speed.