Jean Boussier
@byroot.bsky.social
Rails core, Ruby committer, funemployed.
I was pleasantly surprised by the T-shirts at Rails world. Probably the softest ones I ever got at a conf.
I just checked, the make is "Next Level Apparel".
I just checked, the make is "Next Level Apparel".
November 5, 2025 at 5:27 PM
I was pleasantly surprised by the T-shirts at Rails world. Probably the softest ones I ever got at a conf.
I just checked, the make is "Next Level Apparel".
I just checked, the make is "Next Level Apparel".
What you want to do with the warnings depends a lot on the environment. Forwarding them to Rails.logger isn't necessarily always the best thing to do.
e.g. github.com/Shopify/depr...
e.g. github.com/Shopify/depr...
GitHub - Shopify/deprecation_toolkit: ⚒Eliminate deprecations from your codebase ⚒
⚒Eliminate deprecations from your codebase ⚒. Contribute to Shopify/deprecation_toolkit development by creating an account on GitHub.
github.com
November 5, 2025 at 12:25 PM
What you want to do with the warnings depends a lot on the environment. Forwarding them to Rails.logger isn't necessarily always the best thing to do.
e.g. github.com/Shopify/depr...
e.g. github.com/Shopify/depr...
It's so common Linux basically added an API to do it for you with `signalfd`: man7.org/linux/man-pa...
signalfd(2) - Linux manual page
man7.org
November 2, 2025 at 8:08 AM
It's so common Linux basically added an API to do it for you with `signalfd`: man7.org/linux/man-pa...
That's called the "Self Pipe Trick" It's pretty much textbook how to handle signals in an application with a main IO loop.
November 2, 2025 at 8:00 AM
That's called the "Self Pipe Trick" It's pretty much textbook how to handle signals in an application with a main IO loop.
But generally speaking, I think it's the right approach for integrating Ractors.
Don't try to run entire applications in Ractors, instead find some chunk of computations you can move into a Ractor.
Don't try to run entire applications in Ractors, instead find some chunk of computations you can move into a Ractor.
October 31, 2025 at 11:44 AM
But generally speaking, I think it's the right approach for integrating Ractors.
Don't try to run entire applications in Ractors, instead find some chunk of computations you can move into a Ractor.
Don't try to run entire applications in Ractors, instead find some chunk of computations you can move into a Ractor.
Yeah, that design makes sense to me.
That should allow Puma to accept new requests faster when already relatively busy, but of course won't help with app code latency, so unsure how much that would really help in practice.
That should allow Puma to accept new requests faster when already relatively busy, but of course won't help with app code latency, so unsure how much that would really help in practice.
October 31, 2025 at 11:44 AM
Yeah, that design makes sense to me.
That should allow Puma to accept new requests faster when already relatively busy, but of course won't help with app code latency, so unsure how much that would really help in practice.
That should allow Puma to accept new requests faster when already relatively busy, but of course won't help with app code latency, so unsure how much that would really help in practice.
I think it's an interesting idea, would allow parsing code not to impact latency of applicative threads.
However:
- I think you can do that today, it's orthogonal to the parser.
- I'm not certain how backpressure is done in Puma. Does it stop accepting when all threads are busy?
However:
- I think you can do that today, it's orthogonal to the parser.
- I'm not certain how backpressure is done in Puma. Does it stop accepting when all threads are busy?
October 31, 2025 at 6:49 AM
I think it's an interesting idea, would allow parsing code not to impact latency of applicative threads.
However:
- I think you can do that today, it's orthogonal to the parser.
- I'm not certain how backpressure is done in Puma. Does it stop accepting when all threads are busy?
However:
- I think you can do that today, it's orthogonal to the parser.
- I'm not certain how backpressure is done in Puma. Does it stop accepting when all threads are busy?
That’s much closer than what I would have guessed. With a bit of work it might be possible to close the gap.
I’d be more worried about its accuracy though. It’s always a tough sale to replace something that worked for ages.
I’d be more worried about its accuracy though. It’s always a tough sale to replace something that worked for ages.
October 30, 2025 at 5:36 PM
That’s much closer than what I would have guessed. With a bit of work it might be possible to close the gap.
I’d be more worried about its accuracy though. It’s always a tough sale to replace something that worked for ages.
I’d be more worried about its accuracy though. It’s always a tough sale to replace something that worked for ages.
Yeah, it's the double edged sword of bugs.rubylang.org, it's a big enough barrier of entry that we don't get many low effort bug reports and comments, but also it's far enough removed from where most users are that only a small minority interact with it.
bugs.rubylang.org
October 28, 2025 at 7:24 PM
Yeah, it's the double edged sword of bugs.rubylang.org, it's a big enough barrier of entry that we don't get many low effort bug reports and comments, but also it's far enough removed from where most users are that only a small minority interact with it.
At the end of the day, I'm unsure what visibility Matz has of how Ruby is used by the community, and whether he's trying to cater to it or not.
But either way, as I said in the post, I'm quite tired of arguing for it by now.
But either way, as I said in the post, I'm quite tired of arguing for it by now.
October 28, 2025 at 6:47 PM
At the end of the day, I'm unsure what visibility Matz has of how Ruby is used by the community, and whether he's trying to cater to it or not.
But either way, as I said in the post, I'm quite tired of arguing for it by now.
But either way, as I said in the post, I'm quite tired of arguing for it by now.
Yeah, I don't want to encourage people to spam the bug tracker, this sort of mob steering to get your ways isn't nice.
I guess there is the "like" feature that was added, but not sure it does much.
I guess there is the "like" feature that was added, but not sure it does much.
October 28, 2025 at 6:47 PM
Yeah, I don't want to encourage people to spam the bug tracker, this sort of mob steering to get your ways isn't nice.
I guess there is the "like" feature that was added, but not sure it does much.
I guess there is the "like" feature that was added, but not sure it does much.
Testing is good, but the methodology is all wrong here, see intertwingly.net/blog/2025/10...
And: bsky.app/profile/byro...
TL;DR; It's impossible for frozen string literals to have negative performance impact. At worse they're neutral.
And: bsky.app/profile/byro...
TL;DR; It's impossible for frozen string literals to have negative performance impact. At worse they're neutral.
Frozen String Literals Redux - A More Rigorous Test
intertwingly.net
October 27, 2025 at 6:47 PM
Testing is good, but the methodology is all wrong here, see intertwingly.net/blog/2025/10...
And: bsky.app/profile/byro...
TL;DR; It's impossible for frozen string literals to have negative performance impact. At worse they're neutral.
And: bsky.app/profile/byro...
TL;DR; It's impossible for frozen string literals to have negative performance impact. At worse they're neutral.
The saving aren’t that big because you still need to walk the object tree, and allocate a new slot for every object that isn’t shareable.
So it’s usually not that big of an optimization.
So it’s usually not that big of an optimization.
October 25, 2025 at 12:16 PM
The saving aren’t that big because you still need to walk the object tree, and allocate a new slot for every object that isn’t shareable.
So it’s usually not that big of an optimization.
So it’s usually not that big of an optimization.
Yes, the major bump is unrelated to any specific breaking change.
October 25, 2025 at 11:31 AM
Yes, the major bump is unrelated to any specific breaking change.
Nice, probably worth merging. However while no decision have been made yet, it’s like that ractor move might be entirely removed in the near future because it’s impossible to make it correct in some cases bugs.ruby-lang.org/issues/21208
Bug #21208: `Ractor#send(move: true)` allow moving objects that are on the stack, and used by C code. - Ruby - Ruby Issue Tracking System
Redmine
bugs.ruby-lang.org
October 25, 2025 at 11:30 AM
Nice, probably worth merging. However while no decision have been made yet, it’s like that ractor move might be entirely removed in the near future because it’s impossible to make it correct in some cases bugs.ruby-lang.org/issues/21208
Reposted by Jean Boussier
Back when I joined Unboxed in 2014 there was a bug in the action_caching gem that I fixed for a colleague on another project and released a new version. When he thanked me, I said "no need, I got paid for this - if you'd asked me at the weekend I'd have done it for free" 😂
October 24, 2025 at 6:31 PM
Back when I joined Unboxed in 2014 there was a bug in the action_caching gem that I fixed for a colleague on another project and released a new version. When he thanked me, I said "no need, I got paid for this - if you'd asked me at the weekend I'd have done it for free" 😂
Each subcomponent is owned by a specific maintainer or two: github.com/ruby/ruby/bl... and it's bad etiquette to merge in a lib you are not maintainer of.
There's more than enough full time people to handle all this, they're just not allowed to. 2/2
There's more than enough full time people to handle all this, they're just not allowed to. 2/2
github.com
October 23, 2025 at 3:30 PM
Each subcomponent is owned by a specific maintainer or two: github.com/ruby/ruby/bl... and it's bad etiquette to merge in a lib you are not maintainer of.
There's more than enough full time people to handle all this, they're just not allowed to. 2/2
There's more than enough full time people to handle all this, they're just not allowed to. 2/2
The response time on some of the stdlib is definitely not great, but it's not a problem of lack of people, it's because of how Ruby maintainership is handled. 1/2
github.com
October 23, 2025 at 3:30 PM
The response time on some of the stdlib is definitely not great, but it's not a problem of lack of people, it's because of how Ruby maintainership is handled. 1/2
Maybe not random, but with some determination and a bit of mentoring yes absolutely.
I mention that in my post. Peter started as an intern a few years ago, and now he is probably the most knowledgeable person on the Ruby GC.
I mention that in my post. Peter started as an intern a few years ago, and now he is probably the most knowledgeable person on the Ruby GC.
October 23, 2025 at 11:34 AM
Maybe not random, but with some determination and a bit of mentoring yes absolutely.
I mention that in my post. Peter started as an intern a few years ago, and now he is probably the most knowledgeable person on the Ruby GC.
I mention that in my post. Peter started as an intern a few years ago, and now he is probably the most knowledgeable person on the Ruby GC.