For me jruby is a lot more accessible, so I have been using jruby rather than TruffleRuby. GraalVM is pretty cool though - I don't quite feel it is 100% "ready yet", even if you can go very far with it (statically compiled binaries on linux worked well for me). Some things have a low priority such as swing-support; some got it to work, others did not. I understand that swing is legacy, but still it works out of the box, so IMO it should be supported too. It is only semi-supported and I think this is a problem with some of GraalVM, at the least with fewer-used parts of it.
I feel that this semi-friendly competition between the two projects is not good. I also understand neither wanting to "adjust", and in the process lose options; in particular if jruby would be assimilated, we may run the possibility to have jruby work as-is, without necessarily being tied to e. g. the larger java ecosystem. I use both ruby and java, but being able to function in a smaller way, is an advantage (for ruby; see also mruby). Nonetheless I think both projects should eventually curb down on their ego and present a unified java-centric ruby variant that includes all options that existed BEFORE that. Merging by losing features would be stupid - but remaining separate also is stupid, IMO.
kshahkshah
He seemed like a kind and gentle man. I looked up to him. RIP
semiquaver
Spoke to Chris in person at a conference shortly before he died. What a tragic loss. Rest in peace.
show comments
petercooper
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.)
pvsukale3
I really enjoyed reading Chris's deep dives on Ruby internals.
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...
show comments
jwilliams
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.
For me jruby is a lot more accessible, so I have been using jruby rather than TruffleRuby. GraalVM is pretty cool though - I don't quite feel it is 100% "ready yet", even if you can go very far with it (statically compiled binaries on linux worked well for me). Some things have a low priority such as swing-support; some got it to work, others did not. I understand that swing is legacy, but still it works out of the box, so IMO it should be supported too. It is only semi-supported and I think this is a problem with some of GraalVM, at the least with fewer-used parts of it.
I feel that this semi-friendly competition between the two projects is not good. I also understand neither wanting to "adjust", and in the process lose options; in particular if jruby would be assimilated, we may run the possibility to have jruby work as-is, without necessarily being tied to e. g. the larger java ecosystem. I use both ruby and java, but being able to function in a smaller way, is an advantage (for ruby; see also mruby). Nonetheless I think both projects should eventually curb down on their ego and present a unified java-centric ruby variant that includes all options that existed BEFORE that. Merging by losing features would be stupid - but remaining separate also is stupid, IMO.
He seemed like a kind and gentle man. I looked up to him. RIP
Spoke to Chris in person at a conference shortly before he died. What a tragic loss. Rest in peace.
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 really enjoyed reading Chris's deep dives on Ruby internals.
This one to be specific.
https://chrisseaton.com/truffleruby/rubykaigi21/
Rest in peace.
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...
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.
rest in peace Chris Seaton