[ajmurmann]

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.

[regularfry]

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

[mdaniel]

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

[ericb]

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.

[norman784]

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.

[rco8786]

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