Rails is still the king
January 31, 2021 in Ruby on RailsSo, someone asked at work — isn’t Rails a bit too long in the tooth? Should you make new Ruby on Rails apps in 2021, or has it become a legacy stack for boring old jobs?
I’ve been working with Ruby and Rails since 2008, over many different projects: commercial, open-source, hobbyist. I can (and have) talk for an hour about how Ruby and Rails suck. I’ve tried to write my Rails apps in something else multiple times.
And all of this led me to appreciate Ruby on Rails even more. Yes, I would start a new product or a microservice in Rails in 2021.
Ruby on Rails is still the king. But let’s consider, the king of what?
What is it good for?
(Obviously, for some kind of web app. Ruby is also great for scripting, but I’ll focus on Rails here.)
Rails is superb for a specific but very common scenario: when you need to have lots of complicated business logic, but it doesn’t involve crunching large amounts of data at a time. (Oh, and also, scaling Ruby is expensive.)
It’s such a common scenario that it seems that any web app should be a Rails app (especially if you are a Rails developer). So let’s define the use case from its negative.
Don’t use Ruby for web apps that need to digest lots of data in memory. Or if they depend on holding some active user state in-memory like a multiplayer game. Ruby is a very bad language to do this because of its high memory usage. Sometimes you can delegate the data handling to a database of sorts, which brings me to my next point:
Not all apps need complicated server-side logic. Modern software development shifted to doing more on the frontend, so very often, a simple sync service or a database-as-API is enough, and Rails is overkill. (This is my preferred approach these days.)
I used to believe Ruby is slow, but for web requests, it’s fast enough. Rarely did I have to optimize Ruby code in terms of CPU performance.
Why is it so good?
Rails is a remarkable framework. But by now, people translated Rails into every popular language, and no clone is as successful. So my opinion is, Rails is only possible with Ruby.
To put simply — Ruby is a remarkably literate language. It’s easy to write, and it’s easy to read. And, for regular web applications — complicated, but not dangerous — this is what we need the most.
So, why is it so great to write this complicated logic in Ruby, and not some other language, with a robust typing system, a solid concurrency model, and maybe even (imagine that!) no more NoMethodErrors?
Firstly, Ruby is decidedly synchronous.
In Ruby, practically all operations — file I/O, networking, database access — are synchronous. Yes, in the last years, programmers have learned the “joys” of asynchronous programming, mostly thanks to Javascript. And we learned that blocking operations are wasteful and in poor taste.
But what a breath of fresh air that is — to call a method and receive the result, without having to divide code into callbacks or ever think about concurrency. It makes programs a whole order of magnitude simpler. Not only to write but to read and comprehend, too.
So, what about I/O blocking? As it turns out, for a web app that’s usually supposed to return the response in a fraction of a second, being synchronous is just fine. The only downside is CPU idling, but it is mitigated by scaling.
Secondly, Ruby is the champion of lean syntax.
There is no boilerplate and the bare minimum of punctuation in Ruby programs. (My favorite syntactic features are optional parens and the block syntax.)
The syntax is what allows programmers to construct such expressive DSLs in Ruby — most importantly, Rails. But your own business logic is easier to write in Ruby, too. And if you think about it, the lean syntax gave birth to the entire Ruby lifestyle:
REPL is only useful when you don’t need to type in verbose syntax — Javascript REPL is markedly less useful, and so is Elixir’s. The Rails console is the feature I miss the most in other environments.
The culture of using simple text editors like VIM for complex applications also exists because of the simple syntax and readability of programs — of the languages I work with, Ruby is least in need of IDE features.
And readability is what keeps Ruby programs quite reliable and bug-free — the human eye is the best static analysis tool.
If Ruby is so good, why isn’t it everywhere?
Ruby has one major limiting factor — it is extremely memory hungry (because of all the nice language features!) Nowadays, everyone is angry about bloated Electron apps — well, if we had Ruby on the desktop, it would have been much worse.
This is why big Ruby apps remain server-side. A single app running on a server can use more RAM. If you need more throughput, you can always add more servers — it’s not cheap, but it works. It’s a very good tradeoff for the programmer’s efficiency.
A word of advice to the doubtful
Don’t be passively doubtful. Go out and test the technologies that you would like to use. Only you can see what language (and even what branch of programming) works for you, and only from practical experience.
Conversely, don’t feel bad just because you have been only shipping Ruby code for the past 10 years. There is still plenty of demand for server-side applications. And if you keep working in this sector, Ruby on Rails is likely still the best option.
Liked the post? Treat me to a coffee