What does HackerNews think of truffleruby?

From the Truffleruby repo [1]:

> Regarding performance, TruffleRuby is by far the fastest Ruby implementation on the yjit-bench benchmark suite which includes railsbench, etc. To achieve this performance TruffleRuby needs a fair amount of warmup, as other advanced JIT compilers do. If you find any performance issue, please see this guide.

One benefit of YJIT + cruby is it doesn't have the same warmup costs. If you're deploying many times a day, this JIT warmup becomes a dominant factor.

[1] https://github.com/oracle/truffleruby

This is called AOT ;^)

You may want to look into TruffleRuby from Graal, with the "--native" flag. Particularly some of the writings Chris Seaton (project lead/founder) from Shopify has about it:

https://github.com/oracle/truffleruby

Here are a few interesting pieces in Rails specifically:

- https://github.com/hopsoft/stimulus_reflex is inspired by Phoenix LiveView and is getting a bit of traction around me

- https://github.com/hopsoft/cable_ready is a companion project

- https://github.com/discourse/message_bus by Sam Saffron from Discourse is a nice way to implement live updates too, quite easily (video demo at https://twitter.com/thibaut_barrere/status/12565974431075860...)

- https://lamby.custominktech.com is a Rails + AWS Lambda integration which is also gaining a bit of traction

I also see interesting stuff in Ruby more generally these days:

- my own https://www.kiba-etl.org (data processing framework) is growing nicely

- https://sidekiq.org is very solid and used in most Rails app I've seen

- https://github.com/contribsys/faktory allows interop-jobs (e.g. create from Ruby, consume from something else), which is also interesting

- https://github.com/oracle/truffleruby is making very good progress

Just a few cherry-picked links, but I definitely think there are some nice evolutions going on in the Ruby world (speaking as someone also using Elixir in production!).

Actually, since this is Graal the Ruby implementation here is almost certainly https://github.com/oracle/truffleruby so you're invoking Ruby in the same compiler _and process space_ that underlies GraalJS (no transpilation to JS needed). That means the JVM can optimize calls between JS and Ruby (inlining JS values into Ruby method call sites, and vice versa).

> As far as I know, it has been tried numerous times and has been an area of active research in the past, but results turned out unsuccessful.

TruffleRuby is a Ruby implementation that works exactly by writing an interpreting and passing it through a general partial evaluator. It's successful enough to pass almost all the Ruby spec and to run real Ruby applications including their C extensions.

https://github.com/oracle/truffleruby

You might be interested in TruffleRuby: https://github.com/oracle/truffleruby "A high performance implementation of the Ruby programming language. Built on the GraalVM by Oracle Labs."

Most of these really don't matter as soon as you are using a JIT, and some that seem entirely obvious are much more problematic than you might hope.

Final field values can be changed through reflection and some other methods. The Java Language Specification allows a compiler/VM to ignore changes to final fields, but several libraries require them to be seen. So the that can't be optimised at the bytecode level.

The JIT can optimise final field access for some internal classes, and others if an option is set (see https://shipilev.net/jvm-anatomy-park/17-trust-nonstatic-fin...) and in Truffle based languages like TruffleRuby (https://github.com/oracle/truffleruby) we can tell the JIT that certain things are truly constant, but this can't be done universally for Java.

If you're producing bytecode and you want it to run fast then your best bet is to produce bytecode that is similar to javac's as that's what Hotspot has been tuned to run fast, even if it doesn't look optimal.