<pboling[m]>
In JRuby-dev, MiniTest is able to match errors and their messages. RSpec is not able to, and it fails for both exact string comparison and regex pattern matching. IMO, marginal chance this is an RSpec bug.
<AndyMaleh[m]>
I read quite a bit about TruffleRuby, and it always struck me as just a JRuby clone that is sadly a bit incompatible, thus severly compromising its selling points since I could not port JRuby applications to TruffleRuby without having to make changes. That said, I have been hearing interesting things about [GraalVM Native Image](https://github.com/oracle/truffleruby/blob/master/doc/contributor/native-image.md), but apparently it does not
<AndyMaleh[m]>
do AOT compilation of Ruby code, yet only to TruffleRuby and GraalVM implementation. Anyways, my opinion about all of this is the Oracle projects are only good as experiments, but they do not seem that practical or long-sighted (like not matching the JRuby API with TruffleRuby was a very bad move that renders TruffleRuby almost pointless in my opinion). Also, it seems TruffleRuby might be a good experiment for optimizing Ruby performance,
<AndyMaleh[m]>
the features of TruffleRuby to retire that project and make JRuby be the main Ruby implementation that takes advantage of GraalVM features instead?
<AndyMaleh[m]>
but to be honest, I would never want to use directly. It would be great if JRuby could then import all the optimization results of the TruffleRuby experiment to enable more "practical" use of these optimizations in JRuby. TruffleRuby just seems like a toy Ruby implementation that fragments the Ruby market (kinda like how Rubinius was). I cannot see myself recommending TruffleRuby to people ever to be frank. Can JRuby consider importing all
<AndyMaleh[m]>
I am sorry if I opened a can of worms or struck a very sensitive nerve regarding a topic that everybody avoided in the past. Honesty has always been the best policy for me, so I never tiptoe around any topic. I think tiptoeing only fosters mediocrity and encourages little lies that people tell themselves to feel good while things are getting worse. Anyways, forgive me if you'd rather not answer. I was just brainstorming about TruffleRuby,
<AndyMaleh[m]>
and I thought I'd shoot some ideas here, but If I'm totally off base, forget I said anything for now. Otherwise, thank you for keeping JRuby alive and growing.
<kares[m]>
pboling: might be due jruby-head being in a state of alpha ... last time I checked
<kares[m]>
byteit101: yeah that's smt that might be missing but would need more thought.
<kares[m]>
given the resolving of operation is a potentially 'heavy' operation it made sense to have a separate install and than lock step.
<kares[m]>
at some point I think smt similar worked with JBundler and/or jar_deps.
<kares[m]>
that does not mean doing that at runtime could not work - just like bundler can resolve stuff on demand if everything is local.
<kares[m]>
this is a long shot on my side - the feature looks useful but we would need to revisit our existing options
<kares[m]>
if those are insufficient see how this could fit with existing APIs - as noted for such a feature I would prefer a separate step.
<kares[m]>
for now I just do not like the `maven_require` method being top-level as it's named every such addition should have a second thought 😉
<headius>
Andy Maleh: it's a valid question, no worries
<headius>
We have always been focused on providing the best compatibility and features that we can before we work on performance, so that has meant lagging behind on some optimizations. In general folks seem to find JRuby to be the best option for deploying Ruby apps at scale, and as far as I know we are still the only alt Ruby being deployed in critical production environments.
<headius>
We know many areas of JRuby that are still unoptimized and once we have 9.4 out we will be caught up on compatibility and can spend some months on performance
<headius>
Some of the strategies in TruffleRuby will be useful in JRuby but their runtime is quite different and would limit us to only running on graalvm, so we decided long ago it is not the right approach for a JVM Ruby. As for native aot, we have done proof of concept work to aot compile JRuby with graalvm and will try to provide a real solution this year that includes precompiling Ruby code
<headius>
Best thing anyone can do right now is help finish Ruby 3.0 and 3.1 features on master and file specific perf bugs for real world cases that do not perform as well as they could