TruffleRuby is very capable and deserves to be promoted more. I recently made a JPEG encoder/decoder in Ruby and it's 2-3x times quicker on Truffle. Native dependencies is where you can get caught out, but for pure Ruby, TruffleRuby is fantastic and worth including in your test matrix. (More broadly I think Ruby performance is reaching a point where we should be spinning up pure Ruby alternatives to native libraries, but that's a story for another day.)
I exchanged some e-mails with him because I was writing a series on writing a Ruby compiler in Ruby at the time (now self-hosting but woefully buggy and incomplete still; I pick it up now and again, but it's very much a slow-burn hobby project) and met him at Brighton Ruby after that once. He seemed like a very nice guy (and his very kind - given the very incomplete state of it - overview of my compiler as part of reviewing other Ruby implementations is still something I cherish)
I've used JRuby with some success in production fairly recently to bridge two codebases, one previously in MRI Ruby and another in Java. It honestly worked well, but I always wondered about TruffleRuby and how it would have played out if I had chosen that runtime instead. I may still give truffle a go, but it's on the back burner for now.
Anyone have personal experience with all both runtimes and which jvm interop works better? I kinda wish both had unified their interop APIs better, especially given they used to coexist in the same repo for a time...
I maintain a JRuby-based app. I looked into TruffleRuby a number of times but faced issues each time on that code base, so I could not get to the point where I was able to compare anything. YMMV!
GraalVM is genuinely great -- Native Image and the polyglot story are impressive.
I was put off by the earlier licensing - it was confusing, which wasn't great in a license. The GraalVM Free Terms and Conditions "GFTC" now seems better (curious if people agree?), but I wonder if it came too late.
The decoupling from Java SE was good in many ways, but it also made the future a little less clear too.
Apparently there tends to exist some attrition between both teams, now OpenJDK is having a Python and JavaScript support project, but by integrating CPython and V8, not by reaching out to GraalVM, Project Detroit.
TruffleRuby is very capable and deserves to be promoted more. I recently made a JPEG encoder/decoder in Ruby and it's 2-3x times quicker on Truffle. Native dependencies is where you can get caught out, but for pure Ruby, TruffleRuby is fantastic and worth including in your test matrix. (More broadly I think Ruby performance is reaching a point where we should be spinning up pure Ruby alternatives to native libraries, but that's a story for another day.)
Spoke to Chris in person at a conference shortly before he died. What a tragic loss. Rest in peace.
I exchanged some e-mails with him because I was writing a series on writing a Ruby compiler in Ruby at the time (now self-hosting but woefully buggy and incomplete still; I pick it up now and again, but it's very much a slow-burn hobby project) and met him at Brighton Ruby after that once. He seemed like a very nice guy (and his very kind - given the very incomplete state of it - overview of my compiler as part of reviewing other Ruby implementations is still something I cherish)
He seemed like a kind and gentle man. I looked up to him. RIP
I really enjoyed reading Chris's deep dives on Ruby internals.
This one to be specific.
https://chrisseaton.com/truffleruby/rubykaigi21/
Rest in peace.
Someone replied to his final tweets and ended with “#ChatGPT response”. It seems like the most sad and dystopian thing to me.
I've used JRuby with some success in production fairly recently to bridge two codebases, one previously in MRI Ruby and another in Java. It honestly worked well, but I always wondered about TruffleRuby and how it would have played out if I had chosen that runtime instead. I may still give truffle a go, but it's on the back burner for now.
Anyone have personal experience with all both runtimes and which jvm interop works better? I kinda wish both had unified their interop APIs better, especially given they used to coexist in the same repo for a time...
I maintain a JRuby-based app. I looked into TruffleRuby a number of times but faced issues each time on that code base, so I could not get to the point where I was able to compare anything. YMMV!
GraalVM is genuinely great -- Native Image and the polyglot story are impressive.
I was put off by the earlier licensing - it was confusing, which wasn't great in a license. The GraalVM Free Terms and Conditions "GFTC" now seems better (curious if people agree?), but I wonder if it came too late.
The decoupling from Java SE was good in many ways, but it also made the future a little less clear too.
GraalVM builds upon the research done previously at Sun with MaximeVM [0] and SquawVM [1] (SunSPOTs [2] before arduinos were even an idea).
The Graal folks have their own agenda servicing Oracle DB, Oracle serverless, and less trying to replace the OpenJDK.
See this interview with Thomas Wuerthinger, the founder and project lead of GraalVM.
https://www.youtube.com/watch?v=naO1Up63I7Q
Apparently there tends to exist some attrition between both teams, now OpenJDK is having a Python and JavaScript support project, but by integrating CPython and V8, not by reaching out to GraalVM, Project Detroit.
https://openjdk.org/projects/detroit/
[0] - https://en.wikipedia.org/wiki/Maxine_Virtual_Machine
[1] - https://en.wikipedia.org/wiki/Squawk_virtual_machine
[2] - https://sunspotdev.org/ (site still up, go figure)
[2] - https://jug-karlsruhe.de/assets/slides/sunspot-jugKa.pdf (technical overview)
rest in peace Chris Seaton
Yeah, he was such a great guy. I hope his family is doing well.
Rest in peace.