This post was inspired by this post on why the author thinks "Ruby is still great" and this tweet stating that Shopify (and others) are successful because of Rails, not despite it.
Now, let me first give a little background. I've been a Rails programmer since late 2006. Before Rails I went through PHP, ASP and ASP.NET (like most people at the time).
Back pre-2010, Rails was a force-multiplier, and to some degree still is. It provided a completely new way to do web development, including code generation and all the necessary tooling out of the box. The deployment story was sad until Heroku came on the scene, but we suffered through it because Rails solved a real problem.
After over 10 years of dealing with Rails' problems, I'm not so enthusiastic anymore. I believe it is impossible to write a high quality application in Rails. By high quality I mean it satisfies two properties
- It's easy to implement changes and refactor
- It doesn't crash
Like I said before, Rails was a force multiplier, it essentially allows a non-programmer to sit down and create a web application.
To say that a business is successful or not because of a framework or language is IMO preposterous, a business is successful because you've solved a problem and made something people want. A business is not successful because what you've made isn't worth anything to people.
However, Rails can help before you even get to that stage. I believe many companies in existence today exist because of Rails, not because Rails is great at anything in particular, but because it gave non-technical people the courage to try to build something.
In all my years of experience, I have never seen a high quality Rails application. The first month of Rails development on a new app is great, you're making progress incredibly fast and you're banging out new things all the time. The next couple of months can be a slog and you realize that it's really hard to keep adding things. Usually this is when a team starts writing tests because they realize the situation is not sustainable. After 6 months of work on a Rails application, it has usually ground to a halt and you're spending all of your time untangling a massive nest just to make a minor change.
The worst Rails application I've worked on crashed about 500 times per day on average. If you look at the error-tracker Sentry they give you 10,000 errors a month for free. If you need anything more than the free plan, your application needs to throw 300 errors per day. This is not a strange one-off case, Sentry knows their customers and their pricing is calculated, they know most applications throw more than 300 errors per day.
Now, not all those errors are crashes, but in practice most will be. If you had to tell your boss that you need to upgrade to the paid plan because the application is logging more than 300 errors per day, the correct response from the boss should be "fix those errors then", but it never is; because that would take a massive amount of time and effort, completely contradicting the "productivity" of the framework.
Asking that an application doesn't have bugs is too much to ask, but to ask that it not crash really isn't. Most of the errors in Rails are undefined method XYZ for nil:NilClass, this is a whole class of bugs that compilers have been able to detect for years and years.
So, you could ask, why should I care about quality? So what if my application throws some 500's here and there?
I don't have a great answer to this, if your business is actually solving a real problem, people will use your app even if its slow and crashes a lot. Customers will endure a massive amount of pain as long as you solve their problem. Some markets are more sensitive than others, largely depending on the competetive landscape, but this is generally true.
So if having a crappy application isn't actually costing you anything, why bother trying to write something good?
To me, the answer is what Rails had as its mantra for many years "developer happiness". I know I personally enjoy adding value to an application far more than fixing bugs and playing typechecker, something that the computer (theoretically) can easily do for me.
The reality for me over the past 10 years has been that in any Rails application, 80% of time is spent untangling messes to figure out how to make a change, or fixing bugs. Only 20% of time is spent on actually adding value. That ratio should be flipped around, and there are other languages and frameworks out there that try to do just that.
You mistakenly called Rails "Ruby" in the post title.