Hacker News Reader

Comment by ximus | Hacker News Reader

GraalVM Ruby, more commonly known as TruffleRuby, is actively developed still. As the article states, it adopted YARP already.

View on HN

My understanding is that Shopify still hasn’t been able to migrate to Graal/TruffleRuby, even after 10-years of its development.

Your phrasing could be misconstrued by those not familiar with the history. Shopify hasn't been developing TruffleRuby for 10 years. The entire TruffleRuby project is 10 years old, including the first 12 - 18 months where it was a humble intern project. TruffleRuby (previously called JRuby+Truffle) was initially a research project for testing out optimizations, not a production-quality implementation suitable for deployment. I think it's now a viable deployment target, but that wasn't true 10 years ago.

As you might imagine, there's a lot more to production deployments than simple Ruby compatibility. At Shopify, we've recently modified our CI system to support TruffleRuby and are actively running projects against TruffleRuby in CI now [1]. The TruffleRuby 23.0.0 release coming out in the next day or so includes quite a few compatibility issues we've worked out getting a large Rails app booting. That project is on the order of months, not decades.

YARP will make adoption of TruffleRuby easier. Absent a language specification, implementations like JRuby and TruffleRuby have to match what CRuby is shipping and that by necessity means they lag after CRuby releases. Parser changes are amongst the hardest things to port over. YARP eliminates most of the challenges there.

[1] -- https://railsatscale.com/2023-06-12-truffleruby-in-shopify-c...

Disclaimer: I'm on the TruffleRuby team at Shopify.

> “getting a large Rails app booting”

What does ‘booting’ exactly mean in the context of a web app (Rails)?

The Rails initialization process is commonly called "booting", probably owing to the presence of the config/boot.rb file. It's the loading and execution of code necessary before a request can be processed. Beyond the code that Rails executes, it generally includes the loading of most, if not all, of your application's dependencies and any initialization they may require.

In my experience, the Rails boot stage accounts for most of the compatibility work. If you can't boot the app, you won't be able to serve requests and likely can't run tests. E.g., it was at this step that we learned we needed to support more of the native extension API to get memcached running (†). Once booting we did run into some other compatibility issues, but the lion's share came up during the Rails boot process.

† - As an aside, the memcached gem hasn't seen a release since 2014. Its C code attempts to detect the Ruby version and alter how it sets things up. It predates the availability of TruffleRuby so there isn't any TruffleRuby-specific detection logic in it. Our extension compatibility made it look like we supported CRuby's internal object model and that was causing the extension to try to allocate objects in a CRuby-specific way. A small change to a macro fixed the problem and the rest of the gem ran fine. It's one of those things that we can't fix until we see, but once we do we can fix it permanently.

[1] -- https://github.com/oracle/truffleruby/pull/2871

When do you think Shopify will be running its rails on in production on Truffle?

Also, any thoughts on the recent license change of GraalVN?

I can't commit to a timeline, but can say the work is progressing nicely. I plan to blog more about it as we have details to share.

The GraalVM commercial license change seems like a positive change to me. But, I'm not a lawyer and I'm not speaking on behalf of Shopify. To me, it looks to be in keeping with how the Oracle JVM is licensed and I think that simplifies a lot. The commercial version has some really nice improvements for the native binary and that's been mostly closed off to Rubyists.

Reply on news.ycombinator.com