5 ms·

I wonder what the break even point would be to just have switched to use JVM.

ajmurmann 2y ago
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 2y ago
  Rails on JRuby was a tenable proposition last I looked. Been a while though.
  - norman784 2y ago
    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.
  - mdaniel 2y ago
    I believe TruffleRuby <https://github.com/oracle/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 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 2y ago
    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.
  - rco8786 2y ago
    Still around but it's significantly slower than stock Ruby.
ransom1538 2y ago
To save VM instance costs (not disks)? Probably never.
bastawhiz 2y ago
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.
- parentheses 2y ago
  Stripe and Shopify are such polar opposites. Stripes profit per web request is super high. Shopify has to monetize infrastructure efficiency.

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 2y ago
Rails on JRuby was a tenable proposition last I looked. Been a while though.
- norman784 2y ago
  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.
- mdaniel 2y ago
  I believe TruffleRuby <https://github.com/oracle/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 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 2y ago
  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.
- rco8786 2y ago
  Still around but it's significantly slower than stock Ruby.

ransom1538 2y ago

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

bastawhiz 2y ago

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.

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