I’ve said it once and I’ll say it again: Rails is the least-scalable framework ever when it comes to # of engineers. Someone is surely going to respond “you can just add more instances!” Not what I’m talking about, though it’s bad in that department too.
what alternatives do you find are better when scaling up with more engineers?
Nobody understands the conventions so they cargo cult whatever they found from a blog that was last updated in 2013. Or they find novel and extraordinary solutions to problems that the framework literally already solved. Or they have zero experience modeling things in a database—much less doing it the way ActiveRecord encourages—so every battle is always uphill.
The biggest problem with convention over configuration is when you have a team where nobody understands the conventions. But what else do you expect?
I will happily concede, though, that I do think in that sort of situation that Rails can very easily become worse than other languages/frameworks.
Then of course you can find badly written code in any language, and if a quirky would-be rockstar creates a project thinking about art instead of readability and maintainability, they can definitely create an unmaintainable mess with Ruby on Rails - there is nothing preventing you from doing that.
As the number of developers on the project increases, said probability approaches 1 ;)
[0]: https://docs.ruby-lang.org/en/3.2/Method.html#method-i-sourc...
Rails is very opinionated, and when I've encountered new rails code bases they are easily legible to me and can readily be understood.
Even outside of rails, the largest real pitfalls of clever ruby I've seen are related to gratuitous use of metaprogramming, which one can sometimes encounter if you need to maintain or find a bug in a gem you aren't familiar with.
Maybe your problems weren't with rails, but with the programmers of the code bases you were looking at? I believe it's possible to write unmaintainable code in any language.
There's lots of old, broken shit in the Ruby ecosystem and stuff is constantly breaking because of churn and the lack of meaningful, accessible gradual/static typing. (Elixir roughly in the same boats above.) It also doesn't help that some of the gatekeepers of Rails/Ruby have megalomaniac, reactive personalities who make interacting with them sheer misery and CWOT.
If you want what looks like Ruby compiled, there's Crystal. Go and Rust backend frameworks exist also.
Maybe I've been just lucky in the at max 20 or 30 larger projects I worked on so far.
With the added pain that "me today" and "me two years ago" are often different people too.
Rails shows this exact same collosal pain over longer period of time.
Rails optimizes my happiness today by trading it in for my happiness in a few years.
Anyone who is giving Rails a serious look, should take the time to read Eloquent Ruby. When Rails prioritizes programmer happiness, what Rails is really doing is prioritizing the happiness of the lone rockstar developer who is the sole writer, owner, and operator of that codebase. You can build some code that is, yes, quite eloquent. It will be a complete work of art (and yes, Eloquent Ruby was quite illuminating at how Ruby uniquely helps you to write code as art). It will read like English. Your productivity will be phenomenal. You will feel like you can cure cancer by yourself. But all that flies out the window once you need to share that code with someone else, or inherit a codebase from someone who thought of himself as Da Vinci and his codebase as a modern Sistine Chapel. Then it becomes a colossal pain. Because while the codebase itself might be art, the shared context for how to work within that art is nowhere to be found.