The problem is the "just switching" typically means a full rewrite and has a ton of logistic challenges. Are you gonna higher an entire second team? What happens to feature work on the current system? If you keep going full-throttle on features, you'll never catch up. If you stop developing features for a prolonged time, you are putting your entire business at risk.

Writing new services in Java might help, but still doesn't solve the main issue if your Rails app is a monolith. Breaking up the monolith might be a bad decision and is also super expensive and might even eat lots of the potential performance gains.

Rails on JRuby was a tenable proposition last I looked. Been a while though.

I believe TruffleRuby <https://github.com/oracle/truffleruby> is the state of the art for Ruby on the JVM, and <https://news.ycombinator.com/item?id=33503622> says that Mastodon works on it, so that's one data point. I haven't worked up the emotional energy to try to get GitLab to run on it

JRuby is far behind CRuby, so there are a lot of gems that you can't use, also there are not too many companies investing in JRuby itself, IMHO CRuby it's a safer bet.

I was in a large org that did this for a while. It was extremely painful to be this far off the beaten path.

When you stay in the well trod C Ruby path, you benefit from the hordes of others who cleared the landlines before you. With JRuby, not so.

Still around but it's significantly slower than stock Ruby.

To save VM instance costs (not disks)? Probably never.

Stripe tried switching lots of code to the JVM and it was a huge disaster. Unless you already have lots of small services with clean interfaces and their own data stores that can be incrementally switched, you spend far more time bending over backwards to keep two systems running (one with some limited parity with the other) in tandem.

The cost of running the system is almost never bottlenecked by the performance of the language itself, but rather the responsibilities of the system and cleanliness of the code. Plus, in the migration, you start incurring the cost of your Ruby code calling your JVM code (and vise versa; your systems are almost certainly not a DAG), which almost certainly has higher overhead than whatever speedup you'd get from running code in the JVM in the first place. And then you're sharing protobufs/thrift files/whatever between different languages and libraries of varying degrees of quality (good luck with those Ruby protobufs!).

Before you know it, writing a little tool to optimize your Ruby garbage collector sounds like a really great idea.

Stripe and Shopify are such polar opposites. Stripes profit per web request is super high. Shopify has to monetize infrastructure efficiency.