Maybe you haven't worked on a large production Rails app? Rails takes 3-4x the infrastructure hosting costs as other languages/frameworks. Not to mention the insane testing costs from Ruby test bloat.
This could / was definitely true in the 201x. When most of the world's developers 's wages hasn't gone up evenly, and cost / infrastructure performance was expensive.
But we continue to see cost / performance improving. Ignoring the Rails framework and Ruby VM both together has likely gotten 2x speed improvement. We will get 96 Core Graviton v3 or 128 Core Zen 4 EPYC. Cost / Core performance is coming down and will continue to do so at least until Zen 6.
Depending on your App, somewhere along the line it will surely lean towards Ruby Rails's flavour. Assuming you do value what Rails have to offer.
I am just waiting for fibre/ async ( or something similar ) to be built into Rails and Active Record, along with even faster RubyJIT.
I worked at a very large Ruby shop where errors in production were very expensive. This meant that we spent many times more money on instances running the test suite for every build than we spent on all production servers combined.
I got burnt out on Rails after the third app in a row that I was responsible for upgrading. I appreciate Rails' contribution to web development. It took about a decade for the front end framework-library ecosystem to figure out that MPAs are more effective than SPAs for most apps. Fortunately, Astrojs is part of the ecosystem. It's sortof like the fullstack JS version of Rails/Sinatra...without the ORM which IMO adds incidental complexity.
If you have a thriving business already using Rails, it's difficult to justify moving off of Rails...now that painful upgrades seem to be mostly in the past. However, I do find isomorphic JS components & state management to be a pleasure to develop & maintain compared developing an app in two languages.
come checkout phoenix. you get a lot of the same batterries included benefits of ror but the architecture is more moduler. runtime performance is closer to go-lang and there's a really fantastic websocket and reactive frontend system built in. Erlang OTP takes it a whole other level beyond that too if you're trying to scale up.
If you plan the updates since the beginning, and are up-to-date with what's coming next, you are good. Having the app dualboot, running it in your CI to catch upcoming changes is a easy way to avoid such headaches
It's not easy to automate. As you know Github now works directly off the Rails main branch. They have both core Ruby and core Rails maintainers on staff. They have to find, fix, approve, and merge, introduced bugs every day, as well as deal with Rails bugs themselves in the main branch that emerge. This is a huge overhead cost for keeping software up to date, and does not (and should not) apply to any other company.
That's absolutely not a huge overhead, quite the contrary it has many benefits.
We do the same at Shopify, and running off the edge allow to catch bug much sooner and identify them much easier.
It also very significantly cuts down on maintenance cost because we no longer have to work-around bugs, we can fix them upstream and so a small update.
As for you pointing at the Rails 5 migration taking a very long time, it's true that certain major migrations were a pain this one in particular, but it's because a major API had been removed (attr_protected). We (both Shopify and GitHub) work with the edge also in part to make sure the community won't have to suffer this kind of harsh migrations ever again.
All this to say you are blowing things out of proportion. The Ruby and Rails teams at Shopify and GitHub are not an overhead, they pay for themselves, and any tech company as large as Shopify or GitHub you will find major contributors to the stack they use. e.g. There used to be a JVM team at Twitter (half smaller than Shopify even at peak).
guess what? 99% of the apps are not github, neither shopify. You add to your pipeline some automation with https://github.com/fastruby/next_rails and you are done. I'm maintaing a rails app from 2006, with more than 1000 LC (excluding the 2k specs and views) and we are running on rails 7.1. We had one critical moment around rails 5.2 , but after that we managed to keep our stack always up to date.
Infra is cheap when you're in hyper build mode. When your growth rate stalls and your expenses are greater than your income, infra gets expensive very quick and will kill your company.
But we continue to see cost / performance improving. Ignoring the Rails framework and Ruby VM both together has likely gotten 2x speed improvement. We will get 96 Core Graviton v3 or 128 Core Zen 4 EPYC. Cost / Core performance is coming down and will continue to do so at least until Zen 6.
Depending on your App, somewhere along the line it will surely lean towards Ruby Rails's flavour. Assuming you do value what Rails have to offer.
I am just waiting for fibre/ async ( or something similar ) to be built into Rails and Active Record, along with even faster RubyJIT.