Jean Boussier

I'm not even sure if I'd go as far as "idiot". It's impossible for me to guess what the intention is. They may very well have good intentions, but yeah, kinda doesn't give me the motivation to engage.

It somewhat makes sense to me. That gives a place to get updates, changelogs, etc.

There are a few rubygems like that, e.g. rubygems.org/gems/ejson is mostly an empty gem with a Go binary in it.

So far I think reviewing these normally is a waste of my time, if the person on the other end isn't gonna learn anything, why bother? I might as well do it myself. No?

But then what about attribution? Does the LLM wrangler deserve any credit on the final patch?

I'm a bit lost...

But nowadays I get some PRs that are clearly LLM generated, even the feedback I give is clearly directly pasted in the LLM and then sent back to me. It's basically LLM coding by proxy, which begs the question of what to do?

I'm not even sure why I do that, I guess it's a teaching opportunity?

Sometimes it just needs a quick touch up, and I do it myself, as it's not worth the back and forth.

Something I'm not yet clear on how to handle these days is what to do with obvious LLM PRs on Open Source projects.

When a human submit a PR that needs some work, often enough I'll go through rounds of review to progressively get the PR in a mergeable state.

You should yes.

I mean, that somewhat holds true of at least one of his recent predecessors.

Multiprocessing is the most efficient way to serve Rails apps - Balkan Ruby 2026 You’ve been wondering how many threads Puma should be configured to use, or how much cool stuff you’ll be able to build once you’ve migrated to use fibers an...

Process maxing is the way balkanruby.com/talks/32

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

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