Even SolidQueue behave that way by default.

https://github.com/rails/rails/pull/51426

That's largely the case.

Rails provide an abstracted API for jobs (Active Job). Of course some application do depend on queue implementation specific features, but for the general case, you just need to update your config to switch over (and of course handle draining the old queue).

And yes I proposed to integrate bootsnap into bundler ages ago, but got told to go away.

CircleCI does. And I'm sure many others.

GHA is definitely far from the best, but it works:, e.g 1.4 seconds to restore 27 dependencies https://github.com/redis-rb/redis-client/actions/runs/205191...

> The only way docker caching works is if you have a persistent host.

You can pull the cache when the build host spawns, but yes, if you want to build efficiently, you can't use ephemeral builders.

But overall that discussion isn't very interesting because Buildkite is more a kit to build a CI than a CI, so it's on you to figure out caching.

So I'll just reiterate my main point: a CI system must provide a workable caching mechanism if it want to be both snappy and reliable.

I've worked for over a decade on one of the biggest Rails application in existence, and restoring the 800ish gems from cache was a matter of a handful of seconds. And when rubygems.org had to yank a critical gem for copyright reasons [0], we continued building and shipping without disruption while other companies with bad CIs were all sitting ducks for multiple days.

[0] https://github.com/rails/marcel/issues/23

Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependencies.

The reason for speeding up bundler isn't CI, it's newcomer experience. `bundle install` is the overwhelming majority of the duration of `rails new`.

They indeed replaced Unicorn by Falcon in one application, but falcon is configured in "Unicorn mode" (no concurrent requests). So the gain is effectively 0.

Also note how they don't share any performance metrics, contrary to https://railsatscale.com/2023-10-23-pitchfork-impact-on-shop...

Yes, Ractor local GC is the one feature that didn't make it into 4.0.

> Can't you just have completely separate boxes with their own copies of all classes etc, or does that use too much memory?

Ruby::Box is kinda complicated, and still need a lot of work, so it's unclear how the final implementation will be. Right now there is no CoW or any type of sharing for most classes, except for core classes.

Core classes are the same object (pointer) across all boxes, however they have a constant and method table for each box.

But overall what I meant to say is that Box wouldn't make GC any easier for Ractors.

Ruby::Box wouldn't help reducing contention further, they actually make it worse because with Ruby::Box classes and modules and an extra indirection to go though.

The one remaining contention point is indeed garbage collection. There is a plan for Ractor local GC, but it wasn''t sufficiently ready for Ruby 4.0.

The Ractor experimental status could almost be removed. They no longer have known bugs, and only one noticeable performance issue left (missing Ractor local GC).

But the API was just recently changed, so I think it's better to wait another years.

> I vaguely remember reading Shopify is using Fiber / Rack / Async in their codebase.

Barely. There is indeed this management obsession for fibers even when it doesn't make sense, so there is some token usage there and there, but that's it.

There is one application that was converted from Unicorn to Falcon, but falcon isn't even configured to accept concurrent requests, the gain is basically 0.

As for Rails, there isn't much use cases for fibers there, except perhaps Active Record async queries, but since most users use Postgres and PG connections are extremely costly, few people are using AR async queries with enough concurrency for fibers to make a very noticeable difference.

The stdlib still contains `un.rb` though: https://github.com/ruby/ruby/blob/d428d086c23219090d68eb2d02...

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-...

It no longer make sense today, and any new use of it is a smell.

String can be interned in Ruby, but it’s always possible for an equal string that is not interned to also exist. Hence interned strings can’t benefit from the same optimization than symbols.

You can first compare them by pointer, but on a mismatch you have to fallback to comparing content. Same for the hashcode, you have to hash the content.

It's not that different from `1.times` or `90.chr` which are vanilla Ruby.

> HashWithIndifferentAccess

HashWithIndifferentAccess was an unfortunate necessity to avoid DOS attacks when Symbols used to be immortal. There's no longer a reason to use it today, except for backward compatibility.

My bad, I haven't seriously used Python for over 15 years now, so I stand corrected (and will clarify the post).

My main point stands though, Python strings have an internal representation, but it's not exposed to the user like Ruby strings.

> Article also says PHP has immutable strings. They are mutable, although often copied.

Same. Thank you for the correction, I'll update the post.