byroot

Probably worth linking to https://byroot.github.io/ruby/performance/2025/02/27/whats-the-deal-with-ractors.html in which Jean goes into further detail about some of nuances that go into building these types of data structures.

In particular it is mentioned

"For Ractors to be viable to run a full-on application in, Ruby would need to provide at least a few basic data structures that would be shareable across ractors, so that we can implement useful constructs like connection pools.

Perhaps some Ractor::Queue, maybe even some Ractor::ConcurrentMap, and more importantly, C extensions would need to be able to make their types movable."

Which we see in Mike's library he has started work on a Queue and a Map.

I haven't fully wrapped my head around all the nuances to using Ractors nor have I tried to do anything with them yet. But its encouraging to see the discussion around them ramping up

Yep, I agree with this.

Jean Boussier wrote this execellent examination of CPU bound Rails application and why making use of multi-processes is probably a good idea.

Even if you're not using CPU bound it's still daft to leave performance on the table you don't need to.

For the most part if something is a bit slower than it needs to be it still makes more sense to take the obvious bottle necks out before you rewrite the whole system in another language. Especially with YJIT and forcoming ZJIT availible.

1. https://byroot.github.io/ruby/performance/2025/01/23/the-mythical-io-bound-rails-app.html

> They aren't interned frozen strings

Doesn't matter. The parent claim was:

> You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby

From day one it was possible to freeze strings used in metaprograming. I mean Ruby Hashes do that to strings keys.

> Ruby 3.4 making it unnecessary because it is on by default.

That's incorrect: https://byroot.github.io/ruby/performance/2025/10/28/string-literals.html