I remember when web developers, including me, discovered Ruby on Rails in its beginning in 2005. Most of the people really liked the beauty of the Ruby language (the famous "developer happiness"). They also loved the productivity gain that allowed Rails via its philosophy (Convention over Configuration, Do not Repeat Yourself and its other mottos). It was also one of the very first MVC web framework really easy and fast to use.

At this time, the Ruby performance was totally execrable (it was still Ruby 1.8) and it was a real sore to deploy before mod_passenger, unicorn and other solutions arrived...

Some developers were saying that Ruby was doomed because it was too slow and not easy to deploy.

In the end it proves that a language and framework must first make the developer happy and then consequently this will increase his/her productivity. The language has to be pleasant to use and this was more important than its raw performance or its ease of deployment in production. Those points can always be improved later.

That's exactly what José Valim, the creator of Elixir and former Rails-core developer, puts forward in this excellent article: The fallacies of web application performance.

In this article, he recalls that the basic philosophy of Elixir is the productivity of the developer and the ease of maintenance of the code.

The fact that Elixir is also quite fast is just a "bonus".

A bonus that has a quick impact on developer happiness even if he/she does not use advanced language features : very heavy applications load and boot much faster regardless of the environment and without having to use hacks as pre-loaders.

Unit tests, including those that access databases, run directly in parallel and use all the cores of the machine, and so on.

Finally, developers can focus on other things rather than setting up "background-jobs" or "cache" too quickly, even if it may be necessary after a while...

The question that Rails developers should ask themselves is: why start a new project with Rails? The arguments in favor of the latter are less and less true. Usual answers like : "I do not have time to train or train my team" or "Rails fits me well" (aka "I stay in my comfort zone") resonate in the same subjective way as the arguments against Rails a dozen years ago...

The feeling is that Ruby (the MRI) is struggling to break through the glass ceiling in terms of performance and concurrency. Since version 2, few improvements : the core developers are doing everything to improve performance... in order to have a Ruby 3.0 3 times faster than Ruby 2.0. We can feel some results, but the gains of a few percent each year are light years away from Elixir's current performance... Not to mention the parallelism and concurrent aspect which are already built in Elixir... Moore's law is now obsolete, instead of frequency increasement, the cores multiply and this gives a new opportunity for the Erlang virtual machine.

Over the last years, I was also feeling that I was less and less in line with the Rails philosophy. I'm still extremely grateful to what the framework offered to the web community and to me in the past. But today there are too many points I dislike in Rails and those points are too deep to be changed in its core.

Rails is still awesome to quickly build a small prototype. But it's a nightmare to maintain and keep good and consistent quality when the project is growing. I don't really like ActiveRecord and those bloated models with too many responsibilities and bound to a single database table. I don't like the fact that validations are bound to a model or class and triggered with callbacks. Rails contains too many concepts that I learn to dislike over time by slowly working on bigger projects with larger teams.

Rails projects contain too many hidden and implicit variables hidden in huge class hierarchies and so on. Of course, I've learned to replace pieces : bring service objects, use something else than ActiveRecord, plain Ruby objects and so on. But what's the point in still using Rails if I have to change most of its default conventions? For me a framework is good if you can not only use it when prototyping a new project but if it also assists you in writing maintainable and fast code when it is growing. Rails completely fails on this last point and just let you search and use solutions on your own.

A few months ago I chose Elixir and Phoenix to start a new Web project. This project could have been done without any problem with Rails. It turns out that I chose to step out of my comfort zone to discover this technology and it was a breath of fresh air.

I find what I liked at the beginning of Rails: a small and enthusiast community, very serious and competent people, because generally voluntarily coming from the other languages like Ruby or Python. Most of the questions asked on the Slack Elixir channel were all answered in a few seconds... The community, like Ruby for Rails, is mostly gathered around the Phoenix web framework. Great care is taken in terms of documentation, tests and many guides. Its architecture is infinitely more flexible and less monolithic than Rails.

As said earlier, choosing Elixir and Phoenix is ​​not just about choosing performance, it's also about choosing a code-centric philosophy, with a good focus on context decoupling, maintenance and readability over time. And all that by default.

Some choices and conventions that I set up manually in my Rails projects are found right from the start in Phoenix generators. The way to communicate with databases via the Ecto library is also a pleasure compared to ActiveRecord... Everything is a little more explicit, less magical, while keeping the productive aspect and the syntax beauty of the language.

Should Rails developers turn the page? Maybe not immediately, but it seems well necessary to look and test what is good around... Elixir and Phoenix are now very solid solutions.