Too many ruby versions!!!

[rubyFeedback]

I have been using ruby since many years; and since ~2 years I am learning java.
Getting better at it too! Have it tested on windows too and that works.

So naturally jruby was interesting, and I got it to run on windows as well. (I mention
windows twice here since that is an important target for me, but at home on my main
desktop computer I use linux + MRI ruby).

Today I am testing graalvm - hopefully it'll solve EVERYTHING one day. ;)

But I am working through the tutorial right now.

So right now I have this:

$GRAALVM_HOME/ruby --version

truffleruby 21.3.0, like ruby 2.7.4, GraalVM CE Native [x86_64-linux]

Ok so truffleruby there. I haven't installed any gems yet, just looking at it.

$GRAALVM_HOME just points at /home/Programs/Graalvm/Current; I use
a modified GobLinux system to handle different versions at the same time.

I also have MRI ruby compiled from source:

rubyv

ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux]

And last but not least, jruby:

jrubyv # being my alias for jruby --version

jruby 9.3.2.0 (2.6.8) 2021-12-01 0b8223f905 OpenJDK 64-Bit Server VM 16.0.1+9-24 on 16.0.1+9-24 +jit [linux-x86_64]

So I now have ... ruby 3.1.0, ruby 2.7.4 via truffleruby and ruby 2.6.8 at jruby.

Now I understand that the other ruby versions lag behind MRI, I totally
get it. It changes a lot, not everything is specified or works well - totally
understand both headius' and eregon's complaints. But at the same time,
as a user, I kind of want ... ruby 3.1.0 everywhere!

I guess the MRI problem can not be solved by eregon or headius, so
ok - that's for the ruby core team to want to figure out. But in particular
for the java ecosystem, IMO it really really would be better if graalvm
and jruby could eventually merge one day. I don't know the particulars
and differences in this regard, and how difficult it would be, but from
the user's point of view, it would be soooooo much better if we could
use a "unified code base". And IMO GraalVM seems to have a lot
more momentum so perhaps it would be nice if the GraalVM team
could think about this a bit, to avoid fragmentation of the ecosystem
in the long run.

Again, I understand it is not directly the issue of the GraalVM team
nor truffleruby nor jruby, I get it. I am just saying it would be nice
if we could have the same ruby version everywhere.

I now have to test for ruby 3.1.0, ruby 2.7.4 and ruby 2.6.8 strictly
speaking. (I try to make sure my code works on different ruby
versions, but I kind of stick with MRI's release cycle whenever
possible, so using older versions means to slow things down,
which is why I really really really would love to see at the least
the java ecosystem "unify" on one thing. How this can work
internally, again, I don't know ... I am just giving an opinion from
one particular use case here. Too many ruby versions! I am aware
this is not a super-useful issue request but ... it had to be done.
Now I am off to continue with the graalVM tutorial ... :P )

[eregon]

@rubyFeedback The upcoming TruffleRuby release, 22.0.0 on Jan 18, will have a good part of 3.0.2 support, you can follow at #2453.

Alternatives Rubies will always have a bit of delay, e.g. to avoid wasting time on implementing new features being developed in CRuby which might be removed or changed significantly later in the dev cycle before the release.
In other words, alternatives Rubies always target an existing release, so it's not possible on CRuby release day to have a TruffleRuby release targeting that release.
For TruffleRuby we try to keep this delay at maximum 1 release behind.

Also from experience the CRuby x.y.0 release typically has some issues (because of more limited testing) and so most users won't use it in production until x.y.1.

IMO it really really would be better if graalvm and jruby could eventually merge one day.

I don't think this would help at all.
In fact using separate repositories was completely intentional as you can read on https://github.com/oracle/truffleruby/blob/39d740bd3eb8abafe737656055850fc7b3a4d1dc/doc/user/faq.md#why-did-you-fork-from-jruby
Even when they were part of the same repo there was very little code being shared.
The core & stdlib code for JRuby written in Java is simply not usable for TruffleRuby or would optimize very poorly.

from the user's point of view, it would be soooooo much better if we could use a "unified code base"

Could you explain why?
Maybe you think this would ensure the same Ruby version targeted by both and the same behavior? I don't think that's possible given what I said above.

In terms of compatibility, TruffleRuby uses quite a few stdlib directly from CRuby as C extensions so that should be fully compatible with little efforts from the TruffleRuby team.
For the core library there seems to be no way to share because either C code from CRuby or Java code from JRuby is not usable or would optimize very poorly. The way to share would be to have more of the core library defined in Ruby (very little in CRuby, a little in JRuby, large parts in TruffleRuby).

TruffleRuby does share JCodings+Joni and the parser with JRuby. There are some ideas/plans to share the parser better (reuse as-is and not need modifications), potentially even with CRuby.