Jean Boussier

YouTube video by Euruko [Euruko 2025] “Conquering Massive Traffic Spikes in Ruby Applications with Pitchfork” – Sangyong Sim

TIL that STORES migrated to Pitchfork 🙂

www.youtube.com/watch?v=vOH0...

It depends :) The only way to know is to try.

I really really want to get rid of all the `require` decorators, it's really painful to have huge stacktraces when something break during boot.

And both bootsnap and zeitwerk get frequently blamed for third party issues because of it.

Right, most syscalls on macOS (especially the FS related ones) are generally an order of magnitude or two slower than on Linux.

It's quite awful.

A few % of overall boot time, is pretty huge for Zeitwerk given it is already a few % itself.

Napkin math, that 6% figure would be over a full second saved for Intercom. The 3% for autoloading not so much though.

Right, we mentioned autoload blocks a few years ago. I should try to prototype it.

But I suspect @eregon.me won't like it 😜

In the case of bootsnap it already had to be one, so that optimized helper made sense, for Zeitwerk maybe not?

But also maybe Bootsnap could expose an API that Zeitwerk would use if present?

I'll try to find some time to try it on intercom.

For me personally, boot time is a bit of an obsession, so I'd be happy to shave a few %, but I get that adding a C extension to a gem is no small decision.

Oh but of course GitHub Actions is having an outage right as I push the fix...

I guess it's a sign I should go to bed...

Looks like I can procrastinate some more, I found a way to debug it without rr: github.com/ruby/json/pu...

Well, as I said, I need to stop procrastinating first, so that may take a few months 😅.

I need to stop procrastinating and buy myself a proper development machine that run on Linux, and learn how to use the rr debugger.

I keep running into issues that would be way easier to debug that way...

You might just be able to rip out the bootsnap version of it.

github.com/rails/bootsn...

And the Ruby fallback for other platforms: github.com/rails/bootsn...

There are multiple possible strategies, bootsnap has one cache file per directory. But you could have a single cache file with the entire app tree in it, or one per load path entry.

But in all case, like bootsnap you'd need a user provided cache path. e.g. `Zeitwerk.cache_path = "blah"`.

Yes, you need to stat the dir, but then you save one stat per dir entry.

> I believe forbidding extensions in directories that represent namespaces

Good point.

> but perhaps not a lot boot time/eager loading.

I had a persisted cache in mind, like bootsnap has.

Basically a cache for your `ls` helper. Instead of directly listing the directory, you lookup the cache, compare the cached mtime with the directory mtime, and then use the cached `ls`.

However this mean a bit more config (or convention), and that's an annoying part of Bootsnap. But I guess it could be fully optional and Rails could set it up.

I wonder if there's an opportunity for caching here.

If you had a cache store, you could revalidate the entire directory scan by just checking the directory `mtime`.

That's what bootsnap does.

Could be interesting to try to git blame, but very old changes like this usually end up on one giant initial commit

I would assume it was done for consistency with method calls.

But I'm not familiar with parse.y, perhaps the syntax was shared between arrays and argument list and it came as a side effect.

🎤Meet our next speaker: @byroot.bsky.social — Senior Principal Engineer @ Intercom, Rails & Ruby Core team member, Ruby Prize 2022 finalist.

With 10+ years on large Ruby apps, he’s a long-time committer shaping the community.
🗓️ 15-16 May, 2026
📍 Sofia: balkanruby.com/talks/32

Looks like someone testing some sort of repo migration script.
I don’t think it’s shady, just a bit irresponsible

I suppose they could, but I do expect to be able to ping someone from about any public place on GitHub. I often do and it's very useful.

Got it too. Insta blocked the account.

Definitely an annoying GitHub behavior, but at the same time I'm not sure what they could change.

Docker caching is so arcane and brittle that in the past I basically gave up and did my own cache keys by pushing/pulling intermediate layers at predictable locations.

e.g. REGISTRY/intermediates:bundler-%{SHA1(Gemfile, Gemfile.lock)}

Worked super well.

Of course, but I was working on bootsnap recently, and would really love to make things cleaner.

I think it may be time to try to integrate bootsnap in bundler itself.

> it doesn't address that code expects that $LOAD_PATH only contains Strings.

Rereading the ticket, I'm not sure this is really a big deal. Is that sort of code even common?

Also you'd only be exposed to that if upgrading to newer bundler so there would be plenty of time to adapt?

I think we really should work on getting rid of the require overrides.

I was rereading bugs.ruby-lang.org/issues/16848 just yesterday, I think we should revive that feature request.

Happy to brainstorm it with you if you are interested.

Finally, www.ruby-lang.org/en/ has a new design.

Congrats Marco Roth: 2025 Rails Luminary We are stoked to share that the Rails Core team has announced Marco Roth as the 2025 Rails Luminary.

We were very proud to present @marcoroth.dev with the Rails Luminary Award 2025.

And yes, I was on a secret mission to Zurich 😀.

rubyonrails.org/2025/12/17/m...