| Here is a bit of a critical read of this blog post, from the point of view of alternative Ruby implementations: > instead of having to ship an entire language runtime to production Except they ship the CRuby language runtime in production.
Ruby is not a language that can run without a runtime. > Not only did we not need Java VM-level interoperability So they almost discard the entire idea because they don't need a specific additional feature? > choosing either alternative Ruby implementation would have made for a difficult migration path. So what is it? > Stripe relies heavily on gems with native extensions Yes that's a problem on JRuby (when there is no java extension in that gem), but TruffleRuby supports native extensions, as very clearly stated in many places. > as you can imagine, a multi-million line Ruby codebase over time starts to depend on Ruby-the-implementation, not just Ruby-the-language. Except all serious Ruby implementations know they need to be compatible with whatever CRuby does, not just an incomplete ISO specification of the language.
In fact alternative Ruby implementations match CRuby behavior as much as possible for compatibility, even when it seems weird or makes little sense (they report it in this case but have to match behavior anyway). TruffleRuby might not be 100% compatible with CRuby yet, but I would say it is [pretty close](https://eregon.me/blog/2020/06/27/ruby-spec-compatibility-re...). > To adopt JRuby or TruffleRuby in Stripe’s most important services, we’d have to be able to run all the code or none of the code [of a service]. Well yes, to get significant performance gains, one needs to try new things.
Don't they have a staging environment where they can do experiments? |
Although this may have been a very old impression. Pandemic and lock down has an surprising effect on the sense of time.