Thank you for inviting me.

Yes. Very first time. Directly to Matsue. No stop in Tokyo or anything.

Not so much. Only Matsue.I’m going to see Izumo on Sunday and then back to France.

Right, so, I’m Jean Boussier. I live in France. I work for Shopify as a senior staff engineer. It’s been nine years since I’ve been working there. And I did all sort of stuff. I did some SRE, like, performance and stability and things like that. I added lots of developer tooling around Ruby, and Rails. Right now, I work on the Rails and Ruby infrastructure team. And so we contribute to Rails, Ruby and all our dependencies, basically, hundreds of gems. And I happen to be part of the Rails core team, and a Ruby committer. I also maintain all kinds of gems. No blacklisting.

Yeah, it started quite late, to be honest. Because I grew up in boarding school. So I didn’t have access to computers or anything until very late. And then when I got computers, I did not have internet. So I started doing microcontroller programming assembly, because I was doing electronics in high school. And we started doing Intel 8085 programming. And I was like, oh, boy, this is so much better than soldering components. So then I went to a computer engineering school,

Yes, at the university, and that’s where I learned to actually program because the whole assembly dabbling thing wasn’t proper programming. And I’ve just stayed, I loved it so much I just stayed there.

You mean, like when I started using Ruby? I was going to school two days a week. And I was working as an intern in various companies three days a week. Like I was doing PHP at the time and they said, “Oh, did you see this Rails thing ?”… I just looked it up and I just loved it. So I searched for an internship in Rails and found one in 2008. And I just never used anything else since then. It’s just I was in love with like, it was so consistent. I love consistency. We’ve just a few rules and everything makes sense once you grasp a few basics. All evolved from there and so I just loved it. But I didn’t do much open source at the time. I only really started when I was at Shopify, because it was such a huge code base and so many opportunities to open source parts of our internal systems and also find improvements, because it’s such a big user. Things like, Bootsnap, for instance, was a problem. Our applications were so big that they were taking so long to boot. But we were like, “Okay, what can we do?” So it gave me tons of opportunity to contribute to the community.

Yeah, created. So Bootsnap is actually a rewrite of my prior gem, which was ‘Bootscale’, which was the very first one to do like the load path caching thing. And when a colleague of mine, Burke Libbey, at some point, just rewrote it, because mine was quite wonky, to be honest. Then I took over its maintenance, so I’m the maintainer of Bootsnap.

I don’t know if it was kind of natural. At some point, it’s just we had this thing at Shopify. We were always late on updating Ruby, every year, you know. Every year, you give us a new Ruby for Christmas. But then we were leaving the present unopened for like six months, eight months. I was a bit annoyed by that. So I started doing a lot of ruby-head testing. Testing against ruby-head to first find the bug, report the bug upstream, and also correct our bad usage of the language. And so, since we were getting closer to the edge, it made more sense for us to be able to say, “This is a problem for us.” We were, trying, not necessarily to steer the language, but to contribute our experience. Since we’re big users, contributing our experience and saying: “This would work very well for us”, “This will help us tremendously”, “This will break so much code” etc.

My main focus, is pitchfork, which is a new HTTP server for Ruby. My current obsession, since about a year is that, there’s all this talk about “Ruby is slow” or whatever. But I think Ruby is much faster than people think. But they are using it wrong (laugh). Because people started using a lot of servers and job processors like puma and sidekiq, which use threads, which is great. The common knowledge in the Ruby community is that, oh, it’s all IOs, you’re always doing IOs. So, even though you have the GVL, you can use 5~10 threads, and you’re gonna get speed that way. But I don’t think that’s as true as people think. It really depends on your application. It’s going to depend a lot, but many applications are maybe doing 50% IOs, but that gives you two threads at best. Even if you do exactly 50% IOs, you’re not guaranteed that they’ll want to execute at different times. You maybe have like 50-50, but it may want to execute at the same time. So one of the threads’ going to wait and you’re going to waste performance. So that’s why, recently I asked and implemented a GVL instrumentation API in Ruby, for what’s going to be shipped with Ruby 3.2. To allow people to measure how long their threads are waiting. It could be executing, but are waiting on the GVL. So I want APM services like New Relic and Scout and all these things to show that so that people can say, “Oh, well, I’m using too many threads”.

The second reason people use threads is because they want to reduce their memory usage. Previously, they would use forking servers. And you have this magic thing in Unix which is Copy on Write. So when you fork you don’t actually use twice as much memory and memory is shared until you modify it. So my obsession now is to make Copy on Write with Ruby efficient enough, so that using processes does not cost you more memory than threads or barely more. I want programmers to be able to say, “Hey I’ve fully loaded all my code now”. So you can do all the optimization you can so that Ruby would then be able to write less in memory regions. And the second thing is pitchfork. Currently we fork workers that then process requests. And so all these things like inline caches in instruction sequence and all that disable Copy on Write unfortunately, but then if you let a worker process a few requests, and then you take it out of rotation, and when you ask it to fork again, all these caches are warm. So the next time they won’t be written into. So basically, you pre-warm your application with the first generation of workers and then you create a second generation, but I’ve all these things pre warmed, and I did some some testing, and the results are quite impressive. Again, it totally depends on the application, so don’t take any number like gospel, but it’s like, half the memory usage.

Yeah kind of. I released it a couple of weeks back. And I plan to do some more testing in production at Shopify. But with the Ruby 3.2 release approaching, I had to put it on stop for now. Because now I’m fully committed to testing Ruby as much as possible to ensure a stable release.

Yeah, that’s another thing we were trying to push. Mostly Ufuk that you have met, we have this chance, to have this giant test suite. Even, a week ago, I opened another ticket, due to a crashed caused by a bug in GC. We detected it and GitHub detected it also. Since we talk a lot with GitHub, we convinced them to do ruby-head testing as well. And so now we are able to spot bugs. And since we do we trigger builds, every few hours, we’re able to say, “Okay, it failed when this commit was introduced”. So it makes it so much easier to notice what the bug was and to fix it in advance. For a very long time, the Ruby community has treated .0 releases, like 3.0.0 as beta or RC basically. It was a common thing in the community to say, “Oh, I’m gonna wait for the .1 or .2 to upgrade”. I don’t like to say it, but I have to admit it was true until 3.0 since 3.1. We started doing a lot of testing and reporting lots of bugs. For most of the Ruby committers at Shopify, the first mandate, when we are in November is to make sure if there isn’t any outstanding bug known. It’s your priority to fix it before anything else. I think we managed to do it for 3.1.0. I want us, not just Shopify but also the ruby-core team to improve here.

Yeah, exactly. We have that metric Ufuk compiled. Our average time to upgrade to the latest Ruby at Shopify used to be 300 days. For 3.1, it was seven days. And it’s only because I took vacations actually. From when I came back from vacation, it was less than 24 hours to upgrade. There was no problem.

Oh, it’s great. Actually when I started at Shopify, I was living in Montreal. I chose to go back in France in 2016. I actually love it because I like the quiet, I like to be able to focus. So I’m alone in my office and most of my team is just about everywhere. We have a couple of people in Japan, we have a bunch of people in North America. But it gives me all this focus time. You cannot have that in an office. You have lots of productive discussion in an office but what remote work gives you is like real deep focus where sometimes I just don’t see the time pass. It’s quite crazy.

Yes. From home. Yeah, I just go up the stairs. My commute time is seconds.

I don’t know yet. I think I still have quite a lot of work on the Copy on Write thing. I think it’s going to keep me occupied for at least another year. Probably. Another thing I would like to tackle in the future is, I don’t know if you’re familiar with the HPy project from Python. They’re creating a stable ABI for C extensions. Because the problem we’re having when we do Ruby-head testing is that we have lots of very big native gems like Nokogiri, GRPC all these things. And they usually ship with precompiled binaries, because it’s so much easier for everyone. But when you do ruby-head testing precompiled binaries only work for already released versions of Ruby, because the ABI is not known for the new Ruby. So I would like to do a bit like HPy to do like a very simple C extension, that you recompile every time but that exposes a stable ABI that other C extension can use and that would allow to have precompiled binaries for Ruby-head. That would also simplify the workflow around precompiled extension. The problem is, I’m not smart enough to do that. I have no idea what an ABI is. I don’t know so a good part of my work is not actually to do things is to nerd snipe some smart people in my team.

I’m not so sure, but thank you (laugh).

Thank you for having me.

22 hours on the way there. 35 On the way back.

You’re welcome.

Thank you.