That page takes a while to load with all the iframes though so I'd actually prefer to link to RubyEvents if all talks are there, but that's not reasonable since there are also talks at non-Ruby conferences. Could do a mixed approach with linking to RubyEvents and list the few extra talks directly.

Let me know if I can make a PR about that/to which file or so. If we want to be extensive I recently went through all RubyKaigi+RubyConf talks about TruffleRuby to make truffleruby.dev/talks

Not a request and feel free to do nothing about it, but I noticed some talks from Chris notably www.rubyevents.org/talks/deopti... and www.rubyevents.org/talks/ruby-s... are not included in the TruffleRuby page. Which kind of makes sense since it was called JRuby+Truffle back then 😅

May I suggest including bsky.app/profile/truf..., maybe in the next edition?

Yeah that's pretty shady behavior, seems worth reporting. I usually leave a comment to let people know the spam they are causing in such cases. Pretty weird to copy issues like that.

Not entirely sure because I haven't tried in a while but worth a shot. It might also depend on which parts you use so I'd suggest to try it and see.

@statitudes.com Maybe you could try running the full benchmark or even the full app on TruffleRuby?

I ran your benchmarks from bugs.ruby-lang.org/issues/21824 on TruffleRuby with a slight tweak to use benchmark-ips for warmup and the result is 2.42x faster than CRuby 3.4.8 on the first benchmark and 4.66x faster on the second/minimal benchmark!
See gist.github.com/eregon/e3692... for details.

See bugs.ruby-lang.org/issues/21830, so it seems require overrides are ignored.

Mention in the title and social post, if it wasn't clear.

Is this intentionally misleading? Because you should clearly mention this only benchmarks `java -version` and not any relevant benchmark.

Koichi gave a talk at VMIL about it: youtu.be/pqDMne677Ww?...
The code is at github.com/ko1/astro
naruby uses the Prism C API for parsing: github.com/ko1/astro/tr...

And regardless of that, I think this is still a bug of Ruby::Box, it needs to support redefining require. I think the way it works is Zeitwerk gets called first and then doesn't super in the original Kernel#require.

It sounds good to make require more flexible but OTOH it seems like a big design space and lots of work. I like the idea in bugs.ruby-lang.org/issues/16848..., though it doesn't address that code expects that $LOAD_PATH only contains Strings.

Doesn't Ruby::Box respect overrides of require, like done by Zeitwerk?

Regarding that last thought, it'd be pretty cool if a published gem would have the necessary metadata to recompile it on a different Ruby version or different Ruby implementation.

Nice summary post!

By "universal" I thought you meant compile once (per platform), run on any Ruby and it just works, i.e., this is something that HPy has with universal binaries.
So then we wouldn't have to recompile e.g. on 4.0.0, or the next best thing it would be automatic.