Documentation, TruffleRuby, JRuby and oldschool GUI elements - a meta-issue (but please do feel free to close it at any moment in time)

[rubyFeedback]

Hey there truffleruby folks and everyone else who may read this.

I am not a programmer by trade; my background is actually molecular biology, but I did write quite a bit
of code over the years, e. g. via the "bioinformatics" bridge. Even then I consider myself more a biologist
than a hacker/programmer. Anyway, that is just a bit of background.

I discovered ruby many years ago and it's a really great language (if we ignore some oddities).

One of my main projects is bioroebe: https://rubygems.org/gems/bioroebe. It is not hugely elegant or
epic, more a hobby project where I try to cover all "reasonable" use cases for bioinformatics and
molecular biology, if that is possible. For instance, translating all open reading frames in a DNA or
RNA sequence into a aminoacid sequence, on all six reading frames (three on one DNA strand,
three on the other; three because one codon is read as a contig of three nucleotides, at the
ribosome).

One goal or objective that I have for this project is that I want to offer GUI elements for the user.
The natural choice is www, that is, to make these available in, say, .cgi pages, perhaps .html,
sinatra, rails - wherever we can have a browser, things should work. But, aside from this, I also
like classical GUIs. I spent most time with ruby-gtk3 actually. And I wrote quite a lot of widgets
here.

ruby-gtk3 does not work well on windows.

A few years ago I started to learn (or rather dabble in) Java. I made quite a lot of progress in
the last 2 years in this regard. I am still kind of a newbie, but getting better.

About that time as well I discovered GraalVM and kind of switched to it. So I don't even
use openjdk anymore - graalvm is the way for me to go:

openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment GraalVM CE 22.3.0 (build 19.0.1+10-jvmci-22.3-b08)
OpenJDK 64-Bit Server VM GraalVM CE 22.3.0 (build 19.0.1+10-jvmci-22.3-b08, mixed mode, sharing)

GraalVM works very well. I tested it on windows too and it works.

I even got statically compiled binaries to work on linux, via GraalVM. \o/

That one is REALLY great - and fast. It does not yet work for me on windows, but hopefully
it'll be possible one day.

Anyway. Since I want to be as platform independent as possible, my code should work on
windows too, in particular the GUI stuff.

So, since I wrote some ruby-gtk3 applications, I recently decided to port them to java SWING
too, via jruby.

Today I "finished" (kind of) the alignment widget, that is, where different sequences can be
aligned and then the consensus sequence is calculated and displayed.

The ruby-gtk3 widget looks like this:

https://i.imgur.com/SC02Al1.png

The jruby java swing variant I wrote just now looks like that:

https://i.imgur.com/oHtDQCA.png

So, don't worry that these don't look that pretty. I just wanted to get the functionality
to work; I will improve this visually at a later point in time.

For me the big win here is that this will most certainly work on windows too. I already
tested this yesterday via jruby for another test widget. Hopefully at a later time I can
extend it. Anyone knows libui and libui-ng? And Andy's glimmer GUI? My dream is to
build some kind of IDE for bioinformatics-related activities, and have it "translate"
to different toolkits, including the www. I also intend to make use of JavaFX and
SWT - Andy uses SWT a lot, you can look at his glimmer-specific GUI for these
parts (https://andymaleh.blogspot.com/ and perhaps nebula too
https://github.com/AndyObtiva/glimmer-cw-nebula). Anyway.

You may now wonder "but what does this have to do with truffleruby".

Well. One idea I have is, evidently, to translate the ruby-specific code into a compiled
variant via graalvm+truffleruby one day. I already tested various commandline
applications in graalvm (plain java) and these work, both on windows and on
linux. So that part is ok-ish.

I could not get swing-applications to work on graalvm yet, but other folks reported
that it is possible, e. g. we have to use some inflection (see this one 2 years ago
https://www.praj.in/posts/2021/compiling-swing-apps-ahead-of-time/ he got it
to work, but I don't know how he did it, it's above my current abilities to
understand). I am still a noob so I will wait until others smoothen the path for
me to follow. :)

Alright - that's the lengthy introduction and background. With that use case
explained, I would now like to make a few items. Perhaps you guys could
consider some of these use cases in the long run, say, 2023, 2024, 2025 -
just that one day this could perhaps work, or be improved. And as stated
above please feel free to close the issue at any moment in time - I totally
understand keeping the issue tracker clean. See how Jeremy works in regards
to sequel.

(1) JRuby versus Truffleruby dichotomy/split:

truffleruby has some kind of history in regards to jruby. I don't want to go
back in history, and there is cooperation between the projects, also in
regards to ruby specification; and change takes time, I get it. Consensus
has sometimes be reached. That takes time too.

BUT!

From a user's perspective, ideally I'd love to have "just one ruby-java thingy".
Note that I mean that we should RETAIN the flexibility. So jruby's standalone
flexibility is a GOOD thing. Truffleruby+graalvm promising compilation and
integration into a larger framework is ALSO a good thing. I do not mean this
to LOSE an advantage. The advantages should be retained.

What I am saying is that, hopefully, one day, rather than 500 different
ruby implementations, we could have something to "use just this one
only" and it would have all the advantages and none of the disadvantages.

The ruby specification is also useful for other projects, single-hobbyist ones
such as in natalie. While the author of natalie says he just wants to have
fun, having a correct and working ruby implementation via tests + specs
is a good thing. It may allow more integration with other projects too.
See also matz' work in regards to mruby (unfortunately I don't know C
and C++ so I am more in the java niche/ecosystem now).

(2) Truffleruby + GraalVM + compilation. I have had problems here. For me
it does not work well. I ran out of memory and then the resulting binary
did not work well. This may be graalvm's fault, but at that point I'd just
prefer for things to work. Failure frustrates me a lot. I tend to move to
other things when I run into too much failure - not a good mindset but
it keeps my frustration level smaller when I work on things that I know
I can get to work.

Part of this issues is in regards to documentation and examples. I'd love
for there to be more examples, in particular via GUIs. Tutorials and
such things. Or, in my case, I'd love tutorials that would start from
hello world, and then expand the use case to more complicated stuff,
including use cases on the www but also via GUIs (all of swing,
JavaFX, java-SWT - I'd love to have specific examples. These examples
can be somewhat simple, like a button, an input field - but I would like
to know how I can integrate this into graalvm and the resulting
binary so that it works. For some reason, whatever I am doing right
now, it does not work well. GraalVM did improve quite a bit in the
last +1 year or so, so some of the older problems I had go away,
but the issue of documentation is still kind of a problem, IMO. I'll
check every few months, so things may improve slowl, but that was
one pain point I had here so far).

Anyway. Me writing more jruby + SWING will take some days, weeks,
so that'll take some time - hopefully at the end of 2023 things will
have improved a lot here. It would be kind of cool if we could write
GUIs in ruby (sort of), with java a a "back-end", and, at the least on
the linux platform, even be able to compile these things statically.
That would be really great - the speed benefit I could see with graalvm
is AWESOME. I love ruby, but speed-wise graalvm is like a ferrari.

[eregon]

I'll turn this into a discussion, it seems more appropriate for this, and I'll reply there.

[eregon]

Well. One idea I have is, evidently, to translate the ruby-specific code into a compiled
variant via graalvm+truffleruby one day.

Note that Native Image cannot compile Ruby code ahead-of-time, unlike Java code. TruffleRuby Native is the TruffleRuby interpreter AOT-compiled but no Ruby code is AOT-compiled, it's still interpreted + JITed. https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/AuxiliaryEngineCachingEnterprise/ can be used to save the JITed code of a previous run and reuse it for the next runs (it's not fully supported by TruffleRuby yet but we're working on it).

I could not get swing-applications to work on graalvm yet

Please report specific issues about that to https://github.com/oracle/graal/issues.
If the issue is more about Java interop from TruffleRuby, feel free to ask here or on Slack.

What I am saying is that, hopefully, one day, rather than 500 different
ruby implementations, we could have something to "use just this one
only" and it would have all the advantages and none of the disadvantages.

It's really only 3 Ruby implementations which can run Rails and pass a large number of specs: CRuby, JRuby, TruffleRuby.
They all have different trade-offs.
I don't really imagine this changes much over time.
For instance, TruffleRuby has the best peak performance and supports both --jvm and --native modes (which have their own trade-offs) but only runs on a selected number of platforms (currently linux+darwin * amd64+aarch64 and needs a JDK with JVMCI), JRuby runs on many JVMs and many different platforms, CRuby is the reference implementation and the most used one.
I don't think it's possible to have all the advantages and none of the disadvantages.

Truffleruby + GraalVM + compilation. I have had problems here. For me
it does not work well. I ran out of memory and then the resulting binary
did not work well.

It would be great if you can file an issue with a way to reproduce those problems. It's fine to file it on truffleruby repo and we can move it if needed later.

Part of this issues is in regards to documentation and examples. I'd love
for there to be more examples, in particular via GUIs. Tutorials and
such things.

Do you know such a tutorial for JRuby or Java, which we could take inspiration from? For example something simple yet impressive with Swing or AWT.

The jruby java swing variant I wrote just now looks like that:

Could you share the code for that?
It should be fairly easy to adapt it for TruffleRuby's Java interop, and we can help with that.
At some point we might also consider supporting a subset of the API JRuby uses for Java interop for compatibility with it.