byroot
byroot.github.io · Personal blog · on HN since 2024
Jean Boussier (byroot), a Ruby core and Rails contributor, writes about Ruby performance, JSON, Ractors, frozen strings and Rails internals.
What HN saysCommenters call his posts fantastic and link them for details on frozen string literals, Ractors and IO instrumentation in Ruby.
36HN people shared it
8linked it in comments
46stories submitted
1.7Kstory points
3 months agolast shared
2024people per year2026
Most-shared posts
- 1Database Protocols Are Underwhelming6 people · 130 points · first shared 2025 · 29 comments on HN
- 2Frozen String Literals: Past, Present, Future?5 people · 87 points · first shared 2025 · 38 comments on HN
- 3The Mythical IO-Bound Rails App4 people · 251 points · first shared 2025 · 70 comments on HN
- 4The Pitchfork Story4 people · 17 points · first shared 2025 · discussion on HN
- 5Optimizing Ruby's JSON, Part 13 people · 272 points · first shared 2024 · 62 comments on HN
- 6What's wrong with the JSON gem API?3 people · 69 points · first shared 2025 · 24 comments on HN
- 7What's the Deal with (Ruby) Ractors?3 people · 19 points · first shared 2025 · discussion on HN
- 8Optimizing Ruby's JSON, Part 23 people · 7 points · first shared 2024 · 1 comments on HN
- 9Shrinking Ruby Hashes3 people · 3 points · first shared 2026 · discussion on HN
- 10Unlocking Ractors: class instance variables in Ruby2 people · 82 points · first shared 2025 · discussion on HN
- 11So you want to remove the Ruby GVL2 people · 14 points · first shared 2025 · 1 comments on HN
- 12Optimizing Ruby's JSON, Part 72 people · 14 points · first shared 2025 · 2 comments on HN
- 13Speeding Up (Small) Ruby Hashes2 people · 2 points · first shared 2026 · discussion on HN
- 14There isn't much point to HTTP/2 past the load balancer1 people · 334 points · first shared 2025 · 256 comments on HN
- 15Optimizing Ruby's JSON, Part 41 people · 213 points · first shared 2024 · 44 comments on HN
What HN people wrote when they linked it
thomascountz · 2025-11-18
Here's a fantastic writeup about frozen strings in Ruby and the upcoming changes: https://byroot.github.io/ruby/performance/2025/10/28/string-literals.h…
Azerty9999 · 2025-01-25
There is a highly relevant follow-up post by the author here, too: https://byroot.github.io/ruby/performance/2025/01/23/io-instrumentatio…
jeremy_k · 2025-03-26
Probably worth linking to https://byroot.github.io/ruby/performance/2025/02/27/whats-the-deal-wi… 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
byroot · 2025-11-19
> 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.h…
dudeinjapan · 2025-11-18
Ractors have promise but the implementations up till now haven't had strong concurrency safety. It seems in the latest release some of the heavy-hitter contributors like Jean Boussier (byroot) have taken a detailed look at Ractors and started to clean things up.
https://byroot.github.io/ruby/performance/2025/05/24/unlocking-ractors…
Lio · 2025-08-20
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-b…
milofeynman · 2025-01-03
Kind of answered in part 1 intro: https://byroot.github.io/ruby/json/2024/12/15/optimizing-ruby-json-par…
semiquaver · 2024-12-18
Part 2 is available: https://byroot.github.io/ruby/json/2024/12/18/optimizing-ruby-json-par…