[00:00:02.12] - Robby
Welcome to On Rails, the podcast where we dig into the technical decisions by building and maintaining production Ruby on Rails apps. I'm your host, Robby Russell, and I run Planet Argon. For over 21 years, we've helped teams maintain and evolve long-lived Rails apps, so I tend to approach these conversations through that lens. In this episode, I'm joined by Aaron Patterson, also known online as Tenderlove. Aaron is a senior staff engineer at Shopify and a longtime contributor to both Ruby and Rails Core. He spent years helping improve performance, tooling, and developer experience across across the Ruby ecosystem. Recently, he's been exploring faster gem installs, higher performance FFI, whatever that is, and other low-level improvements that many Rails developers may already be benefiting even if they don't fully realize it yet. Aaron joins us from Seattle, Washington in the United States. All right, check for your belongings, all aboard. Aaron Patterson, welcome to On Rails.

[00:00:53.21] - Aaron
Hi Robby, thanks for having me.

[00:00:56.12] - Robby
So good to get to catch up with you again. So Aaron, Let's start with this. What keeps you on Rails after all these years?

[00:01:02.22] - Aaron
What keeps me on Rails? It's very good. Very good question.

[00:01:07.23] - Robby
Thanks.

[00:01:08.13] - Aaron
I would have to say that my significant other keeps me grounded. She keeps me on, on, on the rails. No, I'm kidding. Well, I'm not kidding about that, but to answer the question seriously, I've been using Rails for like many, many, many years. And the thing that keeps me on it is, first off, it's the easiest way to build a website, like get something done, get an app built. Like still, it is the easiest way. But the other thing that I really like about using Rails is that it keeps up with advancements in web technologies and stuff. So it's not like, not like there was like, oh, we just made this one framework and then it just like stuck there. And then now we're forever, like forever ever done with that. That's just not the case with Rails. We're keeping up with all the latest web technologies and stuff and still making it easy even for someone like me.

[00:02:09.17] - Robby
Tell me more.

[00:02:11.05] - Aaron
I am not good at building websites at all.

[00:02:15.13] - Robby
So, and Ruby on Rails makes it really easy for even knuckleheads like you.

[00:02:18.19] - Aaron
Yes, exactly.

[00:02:19.13] - Robby
That's great. Well, I mean, I know that you're very sophisticated software developer. So out of curiosity, how did you get into building web apps in the first place?

[00:02:29.20] - Aaron
Oh, in the very, very first place, like from the very beginning, forever and ever ago.

[00:02:35.07] - Robby
Sure.

[00:02:35.17] - Aaron
Sure. Uh, I just got a job, dude. Like this is in 1999 was my first web job. It wasn't on Rails 8 though. And I needed a job out of high school and, and a friend of mine was working at Uh, funny enough, a car dealership and was like, our car dealership needs a website. Can you, can you help with it? And I was like, yeah, sure. I'll do that.

[00:03:00.21] - Robby
Was any of that dynamic or is that all pretty much static sites back at that point?

[00:03:04.10] - Aaron
Uh, no, it was dynamic. Like I had to do, I had to do JavaScript programming then. So like I was doing, I was doing JavaScript programming in like around 1999, 2000. It's crazy.

[00:03:14.07] - Robby
Okay.

[00:03:15.07] - Aaron
Yeah.

[00:03:16.03] - Robby
Out of curiosity, was that What other tech stacks were involved in that? Where is that like pushing out through? And if this is going down like a rabbit hole that you don't want to, you would like to forget and compartmentalize that part of your life.

[00:03:28.22] - Aaron
It's good to know where we've come from so we know where we're going. Something like that. Uh, it was, um, all just CGI scripts, like Perl CGI, um, with JavaScript and I I think, I don't know that I ever deployed the website, but if I remember correctly, it was basically just like FTP it to a thing and run it.

[00:03:51.15] - Robby
It's like a CGI bin directory or something.

[00:03:54.08] - Aaron
Yep, exactly.

[00:03:55.19] - Robby
Sounds familiar. And then maybe some Apache in front of that or something.

[00:03:59.07] - Aaron
Yes, I don't even know it, like, I think we used CVS at the time was our like our version control system. But I mean, I only worked at that job for like Uh, like maybe a year-ish.

[00:04:16.04] - Robby
So fast forward to somehow between then and getting acclimated or introduced to Ruby 8 and Ruby on Rails, was your introduction into Ruby and Ruby on Rails website development at that point then?

[00:04:27.18] - Aaron
Yeah. So like, I mean, since then I had just always done, I just always done web development. Like it started off as a job and then it turned into a career, I guess. I'm not sure when that happens, like when you go from job to career. Something, but it—

[00:04:41.15] - Robby
I'm still trying to figure that out.

[00:04:44.02] - Aaron
Maybe, maybe it's still just a job. I don't know. Anyway, the, like, I was just a web developer ever, ever since then. And then I learned about Ruby and Ruby on Rails in— well, I learned about Ruby on Rails from the original, like, Build a Blog thing that David did. And that was like, whoa. But I was doing Ruby before that, not as a, not as a job though, just as like, as a hobby project or hobby like hobby programming. And then when I saw Ruby on Rails, I was like, oh my God, this is it. This is what I got to do.

[00:05:21.20] - Robby
Earlier on, you touched on like, that is still one of the easiest ways in your opinion to build web apps and websites. How is your perspective on what developer experience looks like earlier on back then versus where we're at now with web development? And I don't know if you've actually get to spend much time working with other tech stacks very often or get exposed to them. So. Are you super biased because you're in this bubble or?

[00:05:42.10] - Aaron
Of course I'm absolutely like, I have to, I am absolutely super biased. Like I can't say that I only really work in Ruby and Ruby on Rails. So I'm not sure. Like, I'm not sure. I know like PHP has made a lot of changes recently and improved a lot of stuff. I don't think like Node was very popular for, I mean, I guess it's still popular. I don't know. But like I looked into building a website Or I looked into building apps with Node and it's like, no, no, like this is not the same. The ergonomics are absolutely not the same. I tried out Django a couple years. Actually, this is funny. The first time I tried out Django was at Rails World 8.

[00:06:24.02] - Robby
Oh really? Yes.

[00:06:26.23] - Aaron
I was like, okay, I'm going to give, I'm going to give Django a try. And so I tried it and it was, I mean, it was nice, but like. It didn't seem to have all the same features that we have, like just didn't have all the same bells and whistles included. So I really don't want to pick these things. Like I said, I'm a bad web developer. I really want somebody to just tell me like, no, this is what you got to do.

[00:06:49.02] - Robby
Sure. For those listening, um, I mentioned in the intro, but you work at Shopify. So from what I can tell, it doesn't seem like you probably spend a lot of time working directly on the web apps. Themselves though, right?

[00:06:59.19] - Aaron
No.

[00:07:00.23] - Robby
What does your typical day-to-day look like for you now?

[00:07:03.09] - Aaron
So I'm on a, uh, for me, I'm not sure what to call it exactly. The, I'm on the Ruby infrastructure team and we focus mainly on Ruby interpreter itself. So currently we're working on a JIT compiler. I'm working mostly on JIT compiler. And then we're also working on concurrency and garbage collection. So we're improving concurrency and parallelism, GC, as well as JIT compilation. So that's what our team is mostly focused on.

[00:07:34.16] - Robby
For me, as I'm saying, the village idiot trying to ask these best questions about some of these things on behalf of listeners that might be like, I hear these words or things that come up, like what is JIT compiler? What are Ractors? What is Aaron actually talking about up there? Because as a web developer, when do I potentially need to invoke some of these tools? Are these helping more so on running Shopify in production? Or are these, or is actually a lot of this actually helping just developer ergonomics and experience when you're locally developing and working on your application?

[00:08:07.06] - Aaron
Well, if we're doing it correctly, it should help everybody regardless. I love working on performance. I also love refactoring code. I love working on internals, things like that. But my favorite thing to do is if I can make a system better and nobody notices. I mean, they notice that it's better, but like you upgrade your application, you didn't touch anything and it's just faster and better, right? Like if you break an API, everybody complains about that. But if you like make an app faster and zero people complain about that, like nobody's like, oh my goodness.

[00:08:47.23] - Robby
This is too fast. Do you think there's something about those types of problems? Does it kind of feed a part of your, your brain in the sense that those are tangible measurables that you can do? Like, whereas you're working on a web app and you're like, we're going to add a couple of new features and maybe we're improving our conversions or more signups or retention. Those data points can maybe feel a little bit more abstract where you might get the endorphin kick of like, look, it's faster by 3%.

[00:09:14.18] - Aaron
Yeah, I see what you're saying. I do like the number. I do like being able to see the numbers and be like, ah, we made the graph go down or up or whatever the good direction is, you know, because there's always a good direction. That's exciting. But I think what's more exciting for me is like the problem solving aspect of it, because the goal is to make an app better without changing the app at all. So you don't know, like it's these constraints that I have to work with. And it's like, okay, we're constrained to break zero people's code. And yet somehow improve performance with that thing. So how do we do that? And that's, I think, a really exciting, I mean, for me, for me, it's exciting and fun to work on.

[00:09:59.12] - Robby
Well, what sort of things have you been working on more recently? And like, and what types of bottlenecks typically show up in the Shopify scale?

[00:10:07.09] - Aaron
I mean, we have so much code. That any and every bottleneck can show up. Like, there's no one. I mean, we have memory constraints, we have performance constraints. I think, like, if you think about it from a big picture, our team's mandate is basically to be able to make our applications utilize our infrastructure better. So better utilization of our production machines is essentially our mandate, which is a pretty vague, like a vague goal.

[00:10:46.03] - Robby
Sure.

[00:10:47.09] - Aaron
But it's kind of what our mandate is. So we say like, hey, well, we want to send more requests to a particular machine. Like we need to fit more requests on a particular machine. How do we do, like, what do we need to do that? Like, how do we scale the application to do that? It's not really a bottleneck. It's more like architectural problems. And then like how to solve that particular problem. So we're looking at the web server, GC. Actually, let me, let me spell out the big picture for you. So we're looking at Ractors as multi-core utilization. So how do we use all CPUs on the machine? How do we decrease memory? That's where the garbage collector fits in. And then when we have code running on one particular core, how do we make that code run as fast as possible on that one particular core? And that's where the JIT compiler fixes it.

[00:11:39.16] - Robby
I see. So, okay. So it's coming from all these different perspectives. So it's not necessarily these, these are things that developers are needing to refactor some parts of their Rails app itself to take advantage of these features that we've been adding to Ruby, or are there actual scenarios where those things could come into play?

[00:11:57.04] - Aaron
That's a really good question. There's always, and I think there's always like a tension, kind of. So one thing, I mean, there's some things that do need to change. So for example, Ractors is a new type of, actually it's not that new, it's been around for quite a while, just nobody used it. It's a, so Ractors are like threads except they run truly in parallel. So if you have two Ractors, they're really using two different cores. Whereas people probably remember like previously, if you use threads, you're still stuck on one core. It doesn't matter how many threads you use, you're still only utilizing one core. So Ractors let us truly use multiple cores in parallel, but nobody really used them because they crashed a lot. And also like, uh, it was really funny for some workloads, they were actually slower. Like quite a while ago, somebody reported a bug. They're like, hey, like if I process JSON, like all I'm doing is processing JSON documents. If I'm parsing some JSON and I do it serially, that's faster than if I try to do it in parallel with Ractors. So if I try to do it in parallel with Ractors, it's slower, which is like clearly bad.

[00:13:08.13] - Aaron
So we worked on fixing, like we've been working on fixing those types of things. So those are places where your app might need to change, but hopefully not. Hopefully it's just a web server. So you install a new web server and now all of a sudden you have multi-core utilization.

[00:13:26.00] - Robby
Using that JSON examples, like just break that down a little bit more. Like, is that someone like just running like one of the methods on the JSON library or, and then be like, parse this, or does that already in Ruby get split up into multiple processes and chunk it up or something? Or is it just one?

[00:13:41.20] - Aaron
One thing is, yeah, it depends on how you write it. So like, if imagine you were doing it with threads, you might have like a queue of queue of JSON documents that you want to parse. So you've got a bunch of threads that are popping off of, popping off of that queue. It's the same deal, same deal with Ractors. You may have a bunch of Ractors that are just popping off of the queue and then processing, like parsing the JSON. So the bug that the person reported was like, hey, if I do this one at a time, it's actually faster than trying to do it, like pop off a queue and do it multi-core, multi-core with Ractors. And Like one of the things our team has really been focusing on is making sure that Ractors are fast and usable. Like I highly recommend people start using Ractors, especially with Ruby 4.0. They're fast now and you can do things in parallel with them.

[00:14:29.01] - Robby
Can you think of some examples, maybe aside from the JSON one, where someone with a typical Rails app, maybe is this more like on maybe a background job type of scenario where you have like a type thing versus would you use that in a standard web request response cycle?

[00:14:43.13] - Aaron
Yeah, really great question. I recommend that you just never use it in a request response cycle. Like, I don't expect anybody to be— I think like when I'm thinking about web applications, I think it's, it should be very uncommon for somebody to write like Ractor.new or Thread, even Thread.new inside of their controller. ActionView or whatever, or even your model, because typically you're just like processing some data, sending it to a view, getting the response, sending that off to somebody. There's nothing like necessarily that you're doing in parallel in that case. And one thing I would recommend, like, um, uh, if you're using Rails and ActiveRecord, you should be using the async queries with ActiveRecord. You can get async queries already and it'll do that stuff in the background for you, so you're never actually typing Thread.new in your app. Where I do see somebody typing like Ractor.new, for example, or Thread.new would be background jobs. But even then is like the background job processor would already be doing like implementing that. One really good use case I can see for Ractors is OpenTelemetry, where you're getting a bunch of statistics about your application and then trying to log those statistics somewhere.

[00:15:57.06] - Aaron
A bummer about OTel is that like you'll try to log stuff and it'll happen in a background thread and it's a Thread.new thread. And because of that, your app will actually stall when the thread is executing. Because remember, you can only use one, like only one thread can use a CPU at a time. So in that case, you would want to be using a Ractor.

[00:16:18.10] - Robby
But interesting.

[00:16:19.06] - Aaron
But again, you're not typing Ractor.new in your app. Like that's just, you don't.

[00:16:22.16] - Robby
So it's pretty rare that a developer would need to do that. Is Ractor a something that's found in other programming languages?

[00:16:29.06] - Aaron
I think probably the closest analogy might be Erlang or Elixir. It's basically a message passing, like message passing system, just like Elixir. I think that's the closest thing.

[00:16:44.04] - Robby
And what kind of messages, for the dumb idiot question, what kind of messages are they passing between them?

[00:16:48.16] - Aaron
It's just really any, anything that you want to. So like anything you'd queue up for processing in parallel, any type of producer consumer pattern that you might have, have, uh, for example, like maybe you're taking a bunch of JSON documents, you need to parse it there a lot. I don't know.

[00:17:07.03] - Robby
Is there a lot of Ractor.new in Rails codebase itself?

[00:17:11.06] - Aaron
No, no. One of the things that our team is working on is making, uh, Rails Ractor safe. That's one of the projects that we have in flight at the moment. We want to make it so that you can create a new Rails app, or the current goal is you'll be able to do Rails.new and then run that app inside of a Ractor-based web server. So you'll have a Ractor-based web server with your app running, the new Rails app running inside of it. And what that buys you is you can have one process, which is your web server process, using all, I don't know, 16 cores, however many cores you have. On the machine.

[00:17:51.23] - Robby
Is that then something like in a, a Puma or something that you would be configuring the number of CPUs to be using in that scenario? Or is it just automatically figure that out?

[00:18:00.20] - Aaron
Uh, I think we can automatically figure it out, but you could also specify too, like if you didn't want to use all of them for some reason.

[00:18:08.15] - Robby
What does that actually end up looking like on the server that's running it? Is it running just one Ruby process at that point versus like you might have 8 or 16.

[00:18:17.18] - Aaron
Yep.

[00:18:18.19] - Robby
Historically in, in running on your server.

[00:18:20.20] - Aaron
Yep. So like right now today, like if you're running, well, any web server really, if you want to have multi-core parallelism, you have to be running multi-process. This is true for any web server today. So like if you have 20 cores, you need to be running 20 Ruby processes. Whereas with a Ractor-based web server, you run one process and you can use all 20 cores at the same time. Interesting.

[00:18:43.05] - Robby
That's, that's, that's cool. How did you find yourself into working on these types of performance type problems?

[00:18:50.03] - Aaron
These particular ones are highly, I'd say that they're really, really driven by the needs we have at work, pretty much.

[00:18:59.20] - Robby
Can someone make this better, please?

[00:19:02.15] - Aaron
Yes.

[00:19:03.11] - Robby
Someone nominated you? Yeah. Or you raised your hand?

[00:19:05.22] - Aaron
Like, pretty much. Like, I have an idea. Like, okay, you have to do it now. You own it now.

[00:19:10.22] - Robby
How many people are you typically collaborating with right now on these types of projects?

[00:19:16.01] - Aaron
Oh my gosh.

[00:19:17.04] - Robby
Approximation.

[00:19:18.11] - Aaron
That's a good, good question. I think our team's something like 40 people.

[00:19:24.18] - Robby
Okay.

[00:19:25.01] - Aaron
Something like that. It's a lot of people. Uh, and that's not counting like infrastructure people I got to work with. Cause our team, like our team is really focused on Ruby on Rails internals as well as developer productivity. But that's like just those things. I mean, I got to work with infrastructure folks and app developers, like a whole bunch of, a whole bunch of different people because of this particular work. The infrastructure folks really want a Ractor-based web server because it simplifies their deployment strategies. So that's like that aspect of that. But then we have issues like, oh, I want to, we want to test Ruby Edge Ruby. So we're always testing with Edge Ruby. And sometimes I have to work with application developers because they might write code that doesn't work with Edge Ruby. And so I gotta like, you know, get that fixed. So there's that, those folks as well.

[00:20:19.15] - Robby
Interesting. So about 40 people. And is that something, are you typically like in your role on call to some degree? Do you get called in very often for weird quirky things or is it pretty manageable in a typical 9 to 5?

[00:20:33.07] - Aaron
Uh, I'd say it's fairly manageable. I mean, we have an on-call rotation. We have to be very confident that it actually works before we put it into production. If there's any failures, it's going to fail like now. Right?

[00:20:45.12] - Robby
Yeah, that's, that's fair. Um, and I guess part of that is because the, the, say the shape or the type of business that Shopify is, there's constantly transactions happening. So it's like, I would imagine that things would happen pretty quickly if there was something broken.

[00:21:01.17] - Aaron
Yes. We also have really nice, like really, really nice ways to test. One of our applications is a read-only app. One thing we do is we deploy our own custom version or like our team's custom version of that app, and then we run traffic through it. And since, since we know it's read-only, we know it's not going to impact any customers or anything. So we have a really good way of testing.

[00:21:25.06] - Robby
Interesting. Can you share, speak a little bit to what That read-only app does there?

[00:21:29.10] - Aaron
Yeah, it's called SFR. It stands for Storefront, Storefront Renderer. It just renders all of our, all of our storefronts.

[00:21:38.02] - Robby
So, and then everything else is separated from different services. I'm guessing.

[00:21:41.22] - Aaron
Yeah.

[00:21:42.08] - Robby
So if, uh, my commit goods shop is being rendered through that then?

[00:21:48.04] - Aaron
Uh, no, what we do is we replay traffic on this thing. So real, like production traffic will always be hitting our normal production servers., but we'll replay traffic. We call it shadow traffic. We'll replay traffic through our, our experimental one. And we can even do stuff like compare the output of the experimental one to the known correct one. So we can make sure that everything is working properly.

[00:22:15.05] - Robby
How different is that from like a QA workflow then? And is that like an automated QA type thing or just being able to have that replay? Everything?

[00:22:24.00] - Aaron
It's basically the same. I mean, we can do this for any reason we want to. It doesn't have to be Ruby changes or Rails changes. Like people can just do it. They're like, well, I changed, I don't know, something that's risky. And they, they want to have like an extra layer of protection besides just tests.

[00:22:40.15] - Robby
Is that just running on some like internal servers that your team has access to that's playing there? Are people actually logging in and clicking or is it just like some magic or you don't know? We just know that we we deploy over here and some magic happens.

[00:22:53.01] - Aaron
Yes.

[00:22:54.14] - Robby
Okay. It's nice to have magic.

[00:22:56.10] - Aaron
Yes.

[00:22:57.03] - Robby
Um, are you often then needing to load up the Rails apps themselves very often in your like local development environment or?

[00:23:05.08] - Aaron
Not very often, but we do it for testing. Of course, we're not loading the app to do development work on it necessarily, but we're testing, like testing JIT compiler with it, testing, testing GC, testing parallelism. Different stuff, but it's pretty rare because we have to do like a lot of development work on the JIT compiler before we even get to the point where it's like, ah, let's test, let's test our real application.

[00:23:28.11] - Robby
Right. And is it as simple as like running your test suite locally in that type of scenario?

[00:23:33.12] - Aaron
Or, yeah, I mean, it depends on the pro— like it depends on what we're testing and it depends on the problem, but yeah, pretty much. So like our development environments are very, very, um, automated, I guess. So like, there's a lot of developers at Shopify and we have very good tools to ensure that their development environments are well, like, set up nicely so they're not, they're not like running into any problems.

[00:23:59.09] - Robby
They're not needing to debug the bin/setup script every time.

[00:24:02.04] - Aaron
Yeah, exactly. So an issue with that that is unique to our team is that since we're working on Ruby itself, we have to start mucking with like internal stuff.

[00:24:13.22] - Robby
I see.

[00:24:14.16] - Aaron
So that's like kind of a challenge and it's fine, but like, you know, that's what we do for a living. So yeah.

[00:24:24.03] - Robby
For those listening, like not everybody works on a, at an organization as large as something like Shopify where they have access to teams that are doing these types of things. And, but I think it's always interesting to get a sense of like how those large organizations can spend time to invest on that. Do you feel like there are many tools that you've been able to open source that are speak to the kind of developer experience of just the local environment developer perspective, or?

[00:24:46.07] - Aaron
I have no idea.

[00:24:47.09] - Robby
Okay, great.

[00:24:48.10] - Aaron
I have no idea. It's a whole different team, a whole different department, dude.

[00:24:51.22] - Robby
Different team. Not my, not my problem, but someone else's.

[00:24:54.19] - Aaron
I mean, if they open source it, that's great. Cause honestly, like the way that it sets up our development environments is like pretty magical. I, it's great. Like if you're just doing, if you're just doing like normal app development stuff, it does it for, it does everything for you. It sets it all up for you. Okay!

[00:25:12.17] - Robby
This episode is sponsored by Gemshine— a gem polishing and resetting service. Got gems that are dull? Scratched? Not catching the light like they used to? Gemshine restores brilliance. Clean. Cut. Polish. Then we reset your gem into a fresh piece of jewelry. A new ring, a new pendant, a whole new you. Wait... oh no. No, no, no, no, nooo. I think they mean actual gems. Like jewelry gems? For jewelry.

[00:25:36.03] - Aaron
Like, this is—

[00:25:36.22] - Robby
these are not Ruby gems. Oh my God, what have I done? Robby, I read this like this was for Rails developers, like polish your gems but not reset them into new jewelry. And now I'm picturing someone mailing a Gemfile to a jeweler. No, please do not do that. But if you're a jeweler hobbyist, maybe Gemshine sounds kind of incredible. But if you're a Rails developer, please just ignore this. I have a few calls to make.

[00:26:00.01] - Aaron
Author message was read.

[00:26:00.22] - Robby
Obligation was technically fulfilled.

[00:26:02.01] - Aaron
Host did not verify the audience. Host is now aware. Host deeply regrets this.

[00:26:05.11] - Robby
Gemfile. How often do you feel like you run like Rails new?

[00:26:13.10] - Aaron
Uh, not as often as I should, but when I run, like when I run Rails new, I'm just testing, like I'm mainly just testing Rails itself, right? I'm not making a new app. I can't, I can't remember the last time that I ran Rails 8 to make a new app for real. Like, that's not like me mucking around thing, you know what I mean?

[00:26:35.19] - Robby
Like, more recently you've installed— you started a Django app more recently.

[00:26:41.08] - Aaron
Oh no, I made— are you kidding? I make many— like, I do Rails 8 many times. It's just that it's always like test app 1, test app 2.

[00:26:51.07] - Robby
Yeah, test app 3. Um, what is the best, uh, database in the world? Aaron, can you answer the question?

[00:27:01.02] - Aaron
What is the best database in the world? Nobody's ever asked me that. I mean, how do you quantify best?

[00:27:06.23] - Robby
I don't know.

[00:27:07.10] - Aaron
I don't— I mean, I like SQLite a lot.

[00:27:11.17] - Robby
It's convenient.

[00:27:12.19] - Aaron
Yeah, convenient, easy to use, deployed everywhere. It's great. I like PG You know what we should do? We should do like a tier list and I would put SQLite at S-class. It is an S-class database. I'll put Postgres at like A-class, A-tier database. Well, it's got cool features though. MySQL, that's going to have to be a B. I don't hate it, but it's got like weird quirks.

[00:27:47.06] - Robby
Yeah. Do you feel like that rings true now? I mean, I feel like 20 years ago, if you would ask me, I'm like, oh wait, MySQL has all these weird issues with data validation. And then, but still became like the default in Rails 8. I can disagree with DHH about that all we want, but, um, but I think, uh, do you feel like a lot of those quirks still ring true in the MySQL world? Or do you feel like maybe you're a little disconnected?

[00:28:08.02] - Aaron
Disconnected, dude. No idea. I have no idea. Uh, use MySQL at work. I mean, I used it at GitHub. It's fine. Like, I don't have any complaints, man. They're all good.

[00:28:20.09] - Robby
Why such tiny hands? I'm asking on behalf of our audience. Someone said that that should be a question.

[00:28:28.22] - Aaron
I said, that's a great— that is a great question. I don't even have—

[00:28:31.08] - Robby
I don't—

[00:28:31.21] - Aaron
I gotta— I should have some on my desk, but I don't. Um, I don't know. I thought they were funny and I was like, I gotta get these and then pet my cat with it. And then I gotta take photos with them so that everything I just like to— so I like taking forced perspective photos with them and then posting them online, and I'll be like, oh, this, this tomato is huge. And then it's like— but, but the thing is, I— whenever I do that, it's truly because, like, one time I found like a giant onion at the grocery store. It's like huge onion. I bought it and I'm like, this onion's huge. And then I put the little finger next to it, or the little hand next to it, And it's truly a large onion, but the hand is also tiny. And then people are like, oh, it's just a normal size onion. No, it's actually big.

[00:29:24.23] - Robby
Thanks for digging into that with us. Someone suggested that I ask you that question.

[00:29:29.17] - Aaron
I gotta hand it to you. Or hand it to them.

[00:29:32.07] - Robby
Thanks. Yeah. So when you think about, you know, type of work you do with performance and things in the Ruby ecosystem, so what types of friction things you feel like in the Ruby ecosystem on a technical level have been bothering you lately?

[00:29:47.00] - Aaron
It's really weird. Like since I work on Edge Ruby a lot, I encounter a lot of problems where I'm like, is this just a me problem or is this like a problem that everybody has? You know what I mean? Cause like you're running Edge Ruby and maybe something changed in it and not all the gems in the ecosystem know about Edge Ruby? How would they? So like I get all these, get all these weird, weird problems. One of the things I've really cared about recently is like how quickly can you make a new Rails application? Like when you do rails new, like how fast, how fast is it from zero to zero to Rails app? That's something that I've been really interested in lately. It's important to me because the faster you can make a new Rails app, the, I think more people will be using Rails. I mean, Robby, we live in like the TikTok culture. I mean, you gotta be able to install or otherwise somebody's gonna scroll, you know what I mean? So looking at things like that, that's one of the things that's really been interesting me lately.

[00:31:03.06] - Robby
What types of steps go into that? Is it, you know, when you run a Rails new, uh, you've already installed the Rails gem, correct? So is that installing other additional steps at that point?

[00:31:14.10] - Aaron
Yeah.

[00:31:14.16] - Robby
So what about even the process of even having to install the— I mean, in an ideal world, from my perspective as a developer, I'm like, ah, we have to, you have to install Ruby. Then you gotta install Bundler. Does that come with it now? I forget.

[00:31:26.23] - Aaron
And then.

[00:31:28.01] - Robby
There's multiple steps involved as a developer before you can even get to the point of running Rails 9 and then potentially have to then install more things at that point. So what can we do about that? Yes.

[00:31:38.00] - Aaron
Let's say you're zero, you got zero, you got nothing right now. You got to install—

[00:31:41.01] - Robby
Brand new laptop.

[00:31:41.13] - Aaron
Yeah. Brand new laptop. You got to install Ruby, of course. And then maybe if you're compiling Ruby, you got to install all the dependencies too. So maybe that means you need to install, like, I don't know, some—

[00:31:52.18] - Robby
OpenSSL.

[00:31:53.15] - Aaron
Oh yeah, exactly. OpenSSL. But I think typically people are using stuff like mise or I don't know, I use chruby or Ruby install or whatever.

[00:32:04.15] - Robby
RVM.

[00:32:05.01] - Aaron
Yes. And like, you got to get Ruby installed. And then once you do that, you got to do gem install Rails. And then once you do that, you got to do Rails new. And once you do Rails new, it's got to do a bundle install. So you're spending like all this time installing crap. And I think like, One of the things we can do to speed up the process is providing binary, like binary versions of Ruby, which I think mise is already doing though. As I said, like, since I'm working on Edge all the time, it doesn't help me because I got to compile my, like, I have to compile mine all the time. But that's very, that's very helpful. Another thing is, um, we depend on a lot of, we, when I say we, I'm talking about Rails 8. Rails 8, uh, it depends on a lot of binary or not binary gems, uh, C like native extensions. And if we can get those distributed as binary gems, I think that would be very, very like very, very helpful. One of my colleagues, Edward, has been doing a lot of good work on that, like delivering that specifically.

[00:33:06.16] - Aaron
And he gave a presentation about it at RubyKaigi and the, I don't remember what the percentage decrease was, but it's enormous. Like if you can provide all the, all the gems as binary gems, installation speeds are like, I don't know, a second, 2 seconds, something like that. So, um, I'm hoping that we can have that in our future.

[00:33:28.01] - Robby
For those listening, why has that not already always been how that would be done? Like what, what, what sort of obstacles would have prevented that in the past? And is the tooling and stacks and the hardware that we have that much different than we did 10, 15 years ago?

[00:33:40.23] - Aaron
No, it's just, I think like, hmm, there are a few things that get in the way. Boy, trying to think. There's a lot of aspects, a lot of aspects to this problem. Like in the past, I think we just didn't depend on as that many native extensions. So it wasn't as like, it wasn't as big a deal.

[00:34:01.08] - Robby
We can wait for Nokogiri to see.

[00:34:02.17] - Aaron
Yeah. Yeah. People like, so that's the thing. You remember Nokogiri? Remember Nokogiri installations? Who wrote that anyway?

[00:34:08.19] - Robby
Who was that guy?

[00:34:11.02] - Aaron
And like Mike did very hard work to start distributing like binary versions of Nokogiri and then all of a sudden installation speeds got way better. There are a few things, a few hurdles that we have to overcome in order to have binary gems like that. One is starting with Ruby itself. When you compile Ruby, it adds a bunch of stuff baked in that has, um, absolute paths baked into the binary. So like, like let's say you compile Ruby and install it into /foo. You can't just move it to /bar and have it work all the time. Like it'll work sometimes, but not, not all the time. And this is obviously a problem, like, cause like your username on your computer is probably different than my username on my computer. So when you install, if you install a binary version of Ruby, needs to work in both scenarios, which I think mise has dealt with, but I'm not sure. I don't know how exactly. But that's one, one problem. Another problem is, um, I'm sorry, Robby, we're gonna get in the weeds here.

[00:35:18.12] - Robby
Let's do it.

[00:35:19.18] - Aaron
Ready?

[00:35:19.23] - Robby
Let's get into the weeds. Okay.

[00:35:20.20] - Aaron
I'm ready to get into the weeds. So, uh, when you, like, when you install a gem, the gem name, like the filename itself. So we're gonna pretend we're installing Nokogiri, the binary version. It's gonna be Nokogiri, the name of the .gemfile itself is gonna be nokogiri- the version number, dash, some platform. So let's say we're on Linux, on an x86, it's gonna be x86-linux.

[00:35:46.20] - Robby
Okay. Yep.

[00:35:48.05] - Aaron
Now the problem is that the precompiled gem, like the SO file inside of the .gemfile, that has to be linked against a particular version of Ruby. So like maybe it's linked against Ruby 3.4, but you want that gem to work on 3.4, 4.0, various versions of Ruby. So how do you, like, how do how do you accomplish this? And remember, you only get to download that one file. So how do you, like, how do you do this? The way that people do it is through a technique called a fat binary. And what they do is they'll compile Nokogiri and the Nokogiri Gemfile will actually contain multiple SO files, one for each version of Ruby that it supports. So if you support, I don't know, 4.0, 3.4, and 3.3, if you go unpack that gem, there will be 3 SO files inside of the gemfile itself. And then when you require nokogiri, there's some Ruby code inside of that that looks at the version you're on, and then it goes and requires the correct SO file depending on what version of Ruby that you're on. So this is a bummer because it means like, let the gemfiles are larger.

[00:37:01.02] - Aaron
You had to ship like a bunch of different SO files. That's one problem. So this impacts installation time because you have to download all that. And if you're on Ruby 3.4, you gotta download the binaries for Ruby 4.0 as well as blah, blah, blah, blah, blah. Right? The other problem is, let's say you ship Nokogiri version 2 and it supports Ruby 3.4 and 4.0, but then Ruby 4.1 comes out. What do you do? So it can't use the binary version either. And you can't ship a new version of Nokogiri 2.0 that supports Ruby 4.1.

[00:37:38.04] - Robby
So you're kind of stuck there.

[00:37:39.20] - Aaron
So we, we encounter this problem all the time with gRPC in our applications. Google will ship a gRPC version. And then whenever a new Ruby version comes out, we upgrade to the, we want to upgrade to the new Ruby version, but we can't because we got to wait for Google to ship binary versions of gRPC. That's a huge problem that we have to overcome.

[00:38:03.07] - Robby
Are there some directions you think the team, that we can get around that then? Or?

[00:38:08.12] - Aaron
Yes.

[00:38:09.21] - Robby
What, what, and cause I feel like this is, it's not that unlike, like, I guess if you're working on like, say a Red Hat operating system and you install your, you know, your Red Hat packages or your Debian DB file, um, packages, things like that, when you want to install things and just kind of like the precompile versus compiling it yourself. And I know if you use like rbmv historically, it would, it would basically download it and then compile it against your local thing. And you still had to make sure you had all the, all the appropriate other dependencies you needed to install before that. So, which is why Homebrew can be really helpful, but it's trying to at least standardize that to some degree, but it sounds like it's still like kind of a complicated thing unless, are there different ways about how this stuff is approachable going forward where you can reduce that?

[00:38:54.13] - Aaron
Well, I think—

[00:38:54.22] - Robby
You can do all that extra work.

[00:38:55.22] - Aaron
Sure. We have a couple, a couple things in the pipeline at the moment. I mean, you've got to tackle these problems one at a time, I think. And the first one I want to tackle is the multiple Ruby version issue. So no new version. No, no new version.

[00:39:10.17] - Robby
Great idea.

[00:39:12.13] - Aaron
This, I think this all boils down. It's very, very funny, but this all boils down to literally the name of the Gemfile. Itself. Like, it all boils down to that. And it's because Bundler and RubyGems, I would say they overload the file name. So the file name has meaning to it. And that meaning is the, the platform that you're on. I think the first thing we need to do is get rid of that meaning. So I think that the file name should be meaningless. We can kind of call the file name like an address. So we address the file, we address the gem by its name, its version, and then the platform. I think what we want to do is start addressing the gem by its content. So we should have content, like content addressable gems. So rather than, you know, name-version-platform, it would just be name-version-sha. And the sha is the sha of the Gemfile itself. And if we do that, then we can say like, hey, like I'm going to package only Ruby 3.4 inside this one. And then I'll package Ruby 4.0 in this one. And then, you know, maybe if 4.1 comes out, we do that one.

[00:40:20.18] - Aaron
And we're able to ship all these with different actual gem names. And they'll contain only the content required for that particular version of Ruby. So this is going to require some changes on RubyGems.org side. So when you publish the gem, like it's going to have to calculate that SHA. Like if you take a look at the data that comes back from RubyGems.org, like if you go say, like, tell me the versions you have. It's got a bunch of informational fields like what it depends on, Ruby versions it depends on. And we can bake in like, hey, this one depends on Ruby version exactly 4.0, get this, this particular one for your Ruby that you're on. So that, that solves that problem.

[00:41:04.08] - Robby
Sounds easy. I mean, do you feel like that's going to require much of a change from the end user perspective? Like just a typical developer? Or is that can all kind of fairly be seamless behind the scenes.

[00:41:16.04] - Aaron
I think this is, I think this is going to be something that's completely behind the scenes. Like you don't need to do anything. So presumably the way we can do this is I made this proposal to the RubyGems team, rubygems.org team, and they seem to like it. So I think they're going to do it. Um, we introduced like a v2 API on rubygems.org and older clients will still hit the v1 APIs. Newer clients will hit the, hit the v2 APIs and they'll just go download the new stuff. So hopefully you just like upgrade bundler and then it works.

[00:41:53.23] - Robby
Are there similar patterns we've, we've seen in other programming languages or frameworks that kind of follow that approach? Or is this kind of like Aaron's crazy wild-haired idea that someone, that we're going to be talking to somebody in 10 years from now and be like, what was Aaron thinking?

[00:42:06.23] - Aaron
No, there's, there's other systems. Other ecosystems. I can't remember off the top of my head who else does this, but other folks absolutely do content-addressable data as well. It's just, I mean, I think it's a really big thing in like the Nix world or something. I don't know, man. I'm not good at this stuff.

[00:42:25.22] - Robby
But I love the proposal though. Uh, you know, I'm curious about like, how will this help or change how we think about containers? In the future? Do you think that that's still going to be a useful construct for us to be working? Do you feel like everybody should be working in containers or have much of a thought on that?

[00:42:45.02] - Aaron
Uh, let me tell you my, I would tell you my thoughts on containers, but I gotta keep a lid on it. Okay.

[00:42:51.01] - Robby
I'm kidding. I withdraw the question. Editor, you can please just, just dismiss that.

[00:42:58.06] - Aaron
I, I don't know. I mean, I think I like, I like using containers. I don't know that this change will ever like, will like really impact containers at all. But should make building containers faster. But if you're deploying with containers, it's like probably doesn't matter anyway because you just compiled the— made the container once. I think this is mostly like end user development for folks who are just getting started. Like, I think that the new user experience is the thing I'm concerned with the most. Like, if you're already building containers and you already have this deployment solution and you're like, you have teams that can figure out this stuff, I don't, I mean, I do, of course I care about you, but like, you know, like you have resources to put into this and we can support those use cases just fine. It's really like new user experience that I want to, like, I want to encourage. I think this new user experience helps keep the Ruby ecosystem and the Rails ecosystem running and going. And it should be like high priority for us.

[00:43:57.08] - Robby
You know, like if you're thinking about these people that have yet to ever build their first Rails app and they're trying to get started and you have to start putting together this mental model of like, all right, I need Ruby. What, what are my requirements to even install Ruby? Do I need to install Git? What is that? You know, like some of that gets preloaded on computers these days. Maybe even Ruby's already installed on maybe, uh, this gets, I don't know, does Ruby still get shipped on Apple? On macOS?

[00:44:20.18] - Aaron
It does, but it's an old version. It gives you a warning. It's like, don't use this. It's going to go away.

[00:44:26.05] - Robby
But it's here.

[00:44:27.10] - Aaron
Yeah, it's here.

[00:44:28.05] - Robby
We're giving it to you. Who are these people that are using the, the, uh, provided Ruby version? Does this still include Rails anymore? I remember it did.

[00:44:36.11] - Aaron
No, no, it used to.

[00:44:38.00] - Robby
Yeah. Yeah. That was kind of a big deal then. I'm like, it comes shipped with Rails. You're like, great. That's outdated. All right. But, uh, do you feel like there's other tooling that could optimize the overall experience of installing Ruby and Rails? It's like this one. Is this the dream, like download or just run this one command and it handles those several steps really, really fast. And if you're that new developer that doesn't need to worry about, I already have 3 different versions of Ruby installed on this computer. I have zero Ruby 8, zero Rails 8, or any bundler. I don't even know what that is yet.

[00:45:11.01] - Aaron
I mean, hopefully one thing that was really interesting to me is, um, so at RubyKaigi, Matz gave a keynote and his, his announcements was this thing called this thing he built called Spinel, and it is a Ruby compiler, like AOT compiler. So it could take Ruby code and produce a binary, a binary for you, and you could build portable binaries from Ruby. So imagine like, okay, we're able to build Ruby, build RubyGems as a binary, or build Bundler as a binary, or if we combine the two, like maybe put the two together, turn it into one tool. We could distribute just that. It's like, oh, okay, well now, now installing it just becomes download this package and you have it all. Like you have it all ready. You don't need to compile anything because we've precompiled everything for you. That's something I'm really looking forward to. Uh, it seems like a good, interesting future.

[00:46:07.07] - Robby
Do you think that's likely to be a thing that's shipped by the next version of Ruby or is that even required? Is it a completely separate thing or does it need to be?

[00:46:14.23] - Aaron
I think it's totally a totally separate thing. I need to dig into I have to dig into the project more because it's like, it works with the, the project is Ruby, but they, he eliminated the hard parts. So like it doesn't support, for example, it doesn't support eval. So you would, you can't do any, like you can't do any metaprogramming. Well, you can do some metaprogramming. You can't do any metaprogramming that requires eval. But honestly, that's probably a fine restriction. Like I imagine you could build a RubyGems or a bundler without those particular features and then precompile that and give that binary to people and it automatically bootstraps for them. Right. Cause it's really a bootstrapping problem we need to solve.

[00:46:58.16] - Robby
Do you feel like, from what you know, like, is Matt just scratching some personal itch there, or do you see like some interesting use cases like that?

[00:47:06.04] - Aaron
I think, I think, uh, RubyGems and Bundler are a perfect use case for something like this. There have been people out there for a long time who are like, ah, I switched to Rust or whatever. I'm going to say Zig. 'cause I like Zig. I switched to Zig because I needed to build a command line tool and I wanna be able to distribute the command line tool. If you build a command line tool with Ruby, it's kind of a pain because anybody who wants to install it, they're gonna have to install Ruby as well. And then like, of course it might depend on the version of Ruby that you're using. If you chruby to a different one, then it might mess it up and blah, blah, blah, blah, blah. So if we could distribute it like have a system where we can start distributing Ruby code as executable binaries, I think that's like gonna be awesome.

[00:47:51.06] - Robby
Kind of pivot back a little bit to why do some Ruby gems tend to lean on native code in the first place?

[00:47:59.04] - Aaron
Two reasons.

[00:47:59.16] - Robby
Can we just make Ruby faster?

[00:48:01.02] - Aaron
Yeah, we can. I think I'm, I'll give you the two, the two real reasons and then like my cynical reason. So the two, I think the two real reasons are one is speed, which is like maybe could be debatable. The other one is they need, they need to use a library that's implemented in a different language. So those are the two real reasons. And then my cynical reason is because they don't know any better.

[00:48:32.15] - Robby
Well, they knew enough to do it.

[00:48:34.08] - Aaron
I mean, um, Yeah, that's, I mean, you can know enough to be dangerous, right?

[00:48:40.08] - Robby
Like, that's true.

[00:48:41.05] - Aaron
Like I can learn, I can learn enough Spanish to get myself in trouble, in big trouble.

[00:48:46.20] - Robby
You know, earlier we touched on databases and I just wanted to, I don't know if I was kind of curious if you've ever got to do this. I don't know if you can do this in MySQL or not, but I come from a Postgres background where like a previous boss of mine wrote like an O'Reilly book for Postgres. And so I was kind of indoctrinated really early on in the early 2000s. But one of the things I thought was really cool about Postgres was that you could write basically custom functions or procedure type things in many languages and you could do it with PHP and there was even like a PL/Ruby. You can write Ruby code and do fun experiments. Like maybe have, I always think back to this stupid experiment that I had where I had, I don't know why am I talking right now about this? This is, this is my interview with you, Aaron, but, but more importantly about me. But I thought it would be fun to experiment with the idea of like having a Postgres function that would then load up Ruby gems and then call Ruby gem methods on like some text and then have— so the way if you did like a select RedCloth, cause that was like a textile thing back in the day, you could do that on a blob of text, textile code in your, or in a field.

[00:49:48.21] - Robby
And it would just return HTML in that. You could have done, could have just did this in Ruby, obviously, but I liked that you could do things like that. I knew enough to be dangerous and do silly stuff like that and take Ruby places that it wouldn't normally belong. Um, but yeah, I could have done that with C as well. All that to say is people like to experiment as well. Do you recall any interesting experiments you were, you've been able to do with Ruby where you've used Ruby in a non-typical fashion just because you wanted to see if you could?

[00:50:19.03] - Aaron
I mean, hmm. I, yes, I'm trying to think of. Which one to hire.

[00:50:24.23] - Robby
I'm asking the person that gives all his keynotes are all like, look what I shouldn't have done that I did.

[00:50:30.16] - Aaron
Yes. Actually, one I did was, so SQLite has an API that lets you implement a virtual file system. So you can give it a, like you can say like, hey, instead of using fopen or open and close and all those system calls, you give it function pointers and it's like, okay, I'm going to call those instead of like the system ones. So what I did was I exposed that to Ruby. So every time SQLite wanted to open a file, it would call back into Ruby code and be like, hey, please open a file, like open a file for me. I did two things with this. The first one was, you know how when you're like, when you write a Ruby script, you can put, um, under, under. End at the bottom. And then, and then you just have like data, like any kind of data that you want at the bottom of the file. So I made this script so it was self-contained, so it would store a database, like SQLite would store the database in the file. In the file, yes.

[00:51:38.03] - Robby
Okay.

[00:51:39.23] - Aaron
Like you could run the program and there's no database file anywhere else. It's all just stored. It would modify itself and then like store all the data there. Uh, the other use case I did, I hate to say use case, cause that's like, there's gotta be a better word, like use case of abuse. Yeah. Like use case implies that there's, that there's like use, you know what I mean? Like, like, uh, utility.

[00:52:05.07] - Robby
Yeah.

[00:52:05.13] - Aaron
This is more, this is more just to see if I could, um, the other case that I did was, um, I wanted to store data in HTML tables. I actually got this idea from Chad Fowler. He's like, I think it would be cool if we had a database that stored all the data in tables. So like your table is a table tag.

[00:52:27.04] - Robby
Yeah. Right? Yeah. Which column is this in?

[00:52:30.22] - Aaron
Yeah, you gotta look at the tr for the row and then your td. So I did that, 'cause I thought it would be fun. And yes, you can do those things. They're just not, not useful. I think.

[00:52:48.00] - Robby
Can we workshop this, uh, coining a term for this? If we can't figure out, can we make up one? Is this like an itch case?

[00:52:55.00] - Aaron
Yes. Edge case. Yeah. Not a use case. Itch case.

[00:52:58.12] - Robby
Itch case.

[00:52:59.00] - Aaron
Itch case. Ah, itch case. Yeah.

[00:53:00.23] - Robby
Scratching an itch case. Yeah. Yeah.

[00:53:03.00] - Aaron
I like that. Yeah.

[00:53:04.15] - Robby
It's short. It's only 4, 4, 4 letters. Uh, itch case. There you go. All right. I'm going to go trademark that later. itchcase.com. Can you tell us a little bit about what is FFI?

[00:53:14.19] - Aaron
Ah, yes. Let's talk about FFI. One of my favorite, favorite topics. Favorite, favorite. Yes. This is a great transition since we're on the topic of native extensions. We should talk, we should talk about FFI. This is kind of a long winding story, but since I work on a JIT compiler team, I really, really, really, really want people to write their code in Ruby. And the reason I want that is because our JIT compiler can't speed up anything but Ruby. Like it can only speed up your Ruby code. It can't speed up native, like native code at all. Cause it doesn't understand it. So I really want people to write things in Ruby. But that said, like we were talking about legit use cases of native extensions. And one of those cases is like, hey, I got a library. SQLite, for example, and I want to call into that thing. So I'm gonna write a C extension to do it. And you can do that. FFI is a library that allows us to call into C extensions without writing any C code. Oh, so you describe to it in Ruby the function that you're gonna call.

[00:54:20.20] - Aaron
Like you say, hey, I want to call a function named, I don't know, foo, and it's gonna take an integer and it's going to return another integer. And you tell that to libffi and libffi is like, great, thanks for telling me. And then it sets, it sets up the call for you and then you're able to make that call. Like you can call into it. So it does that like connection. It takes the Ruby side and the native side and it like connects them together. For all the podcast listeners, I'm putting my hands together like it's It's a connection. They're interlocking. They're connecting. And that's great. So what that means is you can write Ruby code, you write pure Ruby code, and then that pure Ruby code is able to execute native extension code. The problem, though, is it's very slow. So I've written many native extensions and I have not used FFI. And the reason is because it's slow. So when you make those calls, it's very slow. I gave a whole talk about why it's slow. So you should— I gave the talk in Japanese though. So maybe don't go watch it.

[00:55:34.07] - Robby
It might be, it might be translation.

[00:55:36.11] - Aaron
There might be translation, but the, the, there's many reasons why it's slow, but it's basically doing a lot of work. Um, so one of the things we want to do, or I would really like to do is I built a project that takes your FFI, your FFI code. So you write in Ruby and it generates a C extension from it. So it takes your Ruby code and then translates it to C. And then we compile the C extension and all of a sudden your code is faster because it's a C extension. That's nice, except that we're back in C extension land, which I said, I don't want you, I don't want C extensions. I want you to write, yeah, I want you to write Ruby code. But you did, you did write Ruby code. You wrote Ruby code and then you got C code out, like it turned into C code. Where this fits with the JIT compiler though is I made it so that when it converts it to C code, the C code includes hints that the JIT compiler knows how to read. So when the JIT compiler comes in and starts compiling these functions, like it's saying, hey, we're gonna do a new SQLite database.

[00:56:42.16] - Aaron
It reads the hints that are inside of the C extension and it uses those hints to generate its own function.

[00:56:48.17] - Robby
Calls.

[00:56:49.14] - Aaron
And then it doesn't use the C extension anymore.

[00:56:52.13] - Robby
Explain that to me again.

[00:56:53.11] - Aaron
It's very, very magic. It is a very, very magic trick.

[00:56:56.08] - Robby
Okay.

[00:56:56.16] - Aaron
So—

[00:56:57.10] - Robby
That makes more sense.

[00:56:58.18] - Aaron
We— So typically you call from—

[00:57:01.10] - Robby
What does a hint look like?

[00:57:02.03] - Aaron
A hint? The hint is just some metadata. It's like— Okay. It's literally just like, oh, this is— the function is named foo. It takes an int. It returns another int. So the reason we want to do this is because I'm going to throw some terminology at you, but I'll explain it. We want to be doing, we want to be doing boxing and unboxing of values inside of the JIT compiler. Boxing and unboxing, what that means is taking a, like, a Ruby integer, for example, and converting that into a C integer. So that would be unboxing it. And then taking the C integer and converting that into a Ruby integer, that would be boxing it. Passing it. So we want to be, we want the JIT compiler to be in charge of doing all that type translation. The reason we want to do that is because we're able to profile and specialize all the machine code that we generate to those types. The issue with the C extension is it's totally opaque. We don't know what types it's going to take and what types it's going to return and what it's going to do with that stuff.

[00:58:01.20] - Aaron
So though that's the problem with C extensions and JIT compilers, this This idea here solves, solves the issue.

[00:58:09.19] - Robby
Can you think of some scenarios where a typical Rails developer might feel like they would want to take advantage of FFI and these tools?

[00:58:17.18] - Aaron
Only if you're writing gems, just like writing Thread.new or Fiber.new. Don't do it.

[00:58:23.12] - Robby
Don't do it. Okay. So if you're, if you're, if you're building it, writing a gem.

[00:58:26.16] - Aaron
Yep.

[00:58:27.12] - Robby
When developers are working on gems. What are some things that you wish that if anyone out there listening, they've never released a gem or even written one, what's, what are a few tips that you would recommend before they were to do that? When do you think it even is appropriate to have a gem versus just having something in your, in your Rails app?

[00:58:48.06] - Aaron
Boy, I don't know. I think that's like a really tough question, especially, especially these days with like LLMs and stuff. 'Cause you could just be like, yo, Claude, make a thing for me. Right? And we can all just do that. Like, I don't need your gem. I can just be like, Claude, I need you to integrate with this third-party library. Yeah, do this thing. So it's getting to be like a, I guess, kind of a tougher question to answer these days. 'Cause I think before AI, I'd be like, okay, anything that doesn't have to do with your So, like, well, actually, I think some of these answers even apply to AI. If it doesn't have to do with your core business, like, I don't know, if you do a third-party API integration, since it's not really part of your core business, that's something you probably ought to pull out into a gem. And it's not necessarily about being a gem in terms of being, like, open source or whatever. It's more about, like, architecting your applications such that it's more maintainable. Because like, if you're, if you're integrating with this third party, like maybe you want to run tests on it independently of your main application, maybe you need to add new features and iterate on that.

[01:00:04.00] - Aaron
And you don't have to iterate on it in tandem with your, with your main app. So that's like the main reason to put things in libraries versus just keep it inside of your application, whether or not you choose to open source it though. That's like, you know, different question, I guess.

[01:00:20.07] - Robby
Yeah. Yeah. I think about that, uh, you know, the scenario where with AI and LLMs now that you could have it or collaborate with it, have it generate a client interface to some API or something. And like, there's probably pros and cons that even doing that or not. Are you outta curiosity using these AI and LLMs tooling much in your work?

[01:00:39.17] - Aaron
Dude, every day. Oh my God. All the time. Yes. Yes.

[01:00:45.14] - Robby
What types of scenarios do you find it to be? I mean, we're recording this, it's second half of May 2026. So I know that by the time this gets published, like the whole world could be drastically different and like, but what, where do you find it to be really, really helpful for you right now?

[01:01:02.16] - Aaron
Um, that's a great question. I'll, I'll share some helpful stuff and then maybe not so helpful, not so helpful stuff. Um, I really, really like it for. Searching through code that I don't understand or I've never seen before. Working at a company with thousands of developers, we've got a lot of huge apps that I've never seen and I need to hop into it. Like, due to the nature of my work, I need to be able to hop into it and figure out what the heck is going on. And I'll tell you, AI is just the bee's knees for doing, doing work like that. Really, really enjoy it. I love, love using it for hobby projects. I built a, I, I need to release this as an open source gem. Well, I've built several things. I built a, I built a JPEG encoder with it, which was very cool. And it's because I got these, like, I got these signs. Okay. That's sorry. We're going to go, we're going to get out. Okay. Sorry. You won't be able to see this on the pod, on the podcast, but I got these, like these things here, these little displays.

[01:02:06.02] - Aaron
You see that?

[01:02:06.15] - Robby
Yeah. Yeah.

[01:02:07.02] - Aaron
Yeah. So I've got these little mini displays and funny enough, you have to like, you can say like they have a web, like a web API, basically like an HTTP API, but you have to post JPEGs to them. Oh yeah. Like, okay, sure. But I want to programmatically generate JPEGs, right? Like I want to make the JPEG, like I want to make stuff and then post it to the thing. So there weren't any JPEG libraries, uh, so I had Claudio make one for me and then posted that there. So I really like it for that. I also made a— oh, a printer. I bought— okay, I bought a printer and it's just like a little photo, like a little photo printer, right?

[01:02:57.02] - Robby
Sure.

[01:02:58.06] - Aaron
And I want to print JPEGs to— or I want to send images to it, but I was worried that like, like when I do print on like for preview, whatever, I was worried that it's doing some processing on the image before it sends it to the printer. Yeah, I'm like, is this changing my colors? Because like I look at the photo and it like doesn't look as good as the monitor.

[01:03:22.18] - Robby
Sure.

[01:03:23.07] - Aaron
And it turns out like the, the real reason is because I need an ICC calibration file for the, for the thing. I'm getting in way too deep here, okay? But, um, I built a little— like, I had Claude build a little, like, printer thing for me so it would connect to the printer and then upload the JPEG. And I know that there is no, like, it's gonna match. Yeah, nobody's doing— like, the data that was on my computer is the same. That was the same data that got sent over the socket to the printer. So I love it for that stuff. Yep.

[01:03:59.03] - Robby
And are the photos coming out a lot more consistent now, or is it just— No, it's just, it looks so much better on my screen, but why doesn't it look like that on my— Yeah, this piece of paper.

[01:04:10.13] - Aaron
I'll tell you the reason. The reason is because the dynamic range on the, on the printer is shit. And I have to— what I have to do is— well, no, I'm not going to do that. What I have to do is I have to map the, I have to map the colors to to the ones that the printer can actually support.

[01:04:28.09] - Robby
So I— that's a problem. So you'll just fine-tune it on, on your processing process.

[01:04:32.21] - Aaron
Yes. And then, yes.

[01:04:33.13] - Robby
And then, then it'll match.

[01:04:35.13] - Aaron
Yeah. The thing I don't— I'll tell you the thing I don't like about AI is we're going to get into— I told you I'd get into that.

[01:04:40.23] - Robby
Yeah, you did.

[01:04:42.11] - Aaron
Um, I'm worried that, like, I, I kind of want to write a blog post about this, but I haven't, like, fully 100% formed my thoughts on it, is that, like, if you and I are working together, we both We're both on the same team working together. And like when we first start working together, you're sending PRs. I'm going to be reviewing your PRs very carefully. And after a while though, I kind of get to know you and I know your work. And depending on how, like depending on your work, whatever, I might review your PRs less and less because I'm like, well, I, you know, Robby knows. Yeah. Robby knows what's up. Like, hey, I trust, I trust his work. Uh, ship it. And I think that like we can fall, I have personally fallen into this trap with AI where it's like, hey, I did a thing. Like I asked it to do a thing. I reviewed it very carefully. It did the right thing. Great. Do it again. Did the right thing. Great. So eventually I start reviewing it less and less and then you fall into this trap where it like it generated some shit and you didn't realize it.

[01:05:44.11] - Aaron
So. Like, I don't know how to, like, reconcile.

[01:05:50.02] - Robby
Yeah.

[01:05:50.09] - Aaron
Yeah. Like, how do you, how do you reconcile that exactly? Like, you can't treat, you cannot treat it like a human. It is not, but like, it is close. Like, it's close enough to trick you into thinking it can do a good job. But in some cases it just like, it just can't. And there's no, you know, there's no signal.

[01:06:06.18] - Robby
Yeah. You can't really apply the same, build up that same sort of like long-term confidence in your, whatever, your agents, your, your AI friend.

[01:06:17.12] - Aaron
Yeah.

[01:06:17.16] - Robby
And as you can with humans. To be fair, I mean, I've also worked with humans where their code has deteriorated over time because they didn't care as much as they used to, or they're on the way out of a job or something. But that, but those were less frequent, I think.

[01:06:32.22] - Aaron
Uh, well, also, I mean, in that case too, you're able to talk to the person and you can find out like what the context like what the context is. Yeah, like what's going on with that. Whereas like, it seems— I don't know for sure, but it seems like the like shit rate is basically random when it comes to an AI. So you don't know necessarily. It's like Claude's not going to be like, oh, I'm, you know, I'm hungover.

[01:06:54.15] - Robby
Sorry about that.

[01:06:57.09] - Aaron
Yeah, you know what I mean?

[01:06:58.09] - Robby
Like, oops, my bad. Yeah, yeah.

[01:07:00.18] - Aaron
It's going to be like, it's going to be just as confident on every single like Every single time you ask it to do something, it's like, oh yeah, I totally did it for sure. Yeah.

[01:07:10.23] - Robby
Do you have, I know that one of the things you, I hadn't thought to bring this up, but I know that like when it comes to navigating, dealing with open source in particular, so you've, you're involved in several open source projects and, and a gatekeeper in a lot of ways. I mean that in the, in the best sense, you're not a gatekeeper. Someone's going to clip this. Ah, oh no. TikTok. It's coming for me. Uh, Aaron gatekeeps everybody.

[01:07:32.18] - Aaron
No.

[01:07:33.04] - Robby
Uh, I'm sure people might accuse people on Ruby on Rails Core for that as well. But aside from that, the, uh, when it comes to protecting the, especially with like security concerns, like people might have about, um, I think you had posted not too, not that long ago that you're getting PRs from people that might be security type situations and they may or may not even fully understand what they're submitting a PR for, but they used an AI tool to help them. Yeah. Try to contribute as someone that works on open source projects as well. Like, that's an interesting challenge where it's like, well, how do we, how do we navigate? Because there's like a more of a flood of them at times, more, more PR volume. And then like the security ones tend to catch our attention the most because especially if they write your email security email address or whatever your team might have set up, be like, hey, this is a thing. Do we need, because it requires you to have a conversation is like, is this real or not?

[01:08:24.18] - Aaron
Yeah.

[01:08:25.21] - Robby
And I mean, just anyone listening, if you wanted to like disrupt an open source project, start hitting their security thing with like seemingly realistic security threats. They're going to get bogged down in just dealing with that. And that's kind of sucks. Yeah.

[01:08:38.07] - Aaron
It's a great way to, great way to do a denial of service attack on a, on a, on an open source team. Yeah.

[01:08:44.09] - Robby
I'm done. I don't want to look at any of this stuff. So please don't do that, everybody. Um, yeah, we, but how do you navigate that?

[01:08:51.01] - Aaron
I, well, the first thing, I mean, the very first thing, like I mentioned this on, I think I mentioned this on my blog. Yeah, I made a short blog post about this. It's like, so on the Rails security team, we were working with the IBB or internet, the internet bug bounty. Yeah. What they would do is like they worked with different open source teams to give pay bounties to security reporters. And then like, it was fine. I mentioned like, I wasn't sure about this program from the start. Cause like when you start paying bug bounties, of course there's going to be people out there who are like, whoa, I want some free money. Right. So they're going to start sending, I don't know, crap basically. Uh, and then, uh, but we like, they dealt with that at first. This was before the AI era.

[01:09:45.01] - Robby
Yeah.

[01:09:45.15] - Aaron
The other issue we would run into is like people who haggle because like the IDB would pay more depending on the severity of the bug. So if it's more severe, they would pay more. So then you get people who are like, oh, this, this bug that like, oh my God, the ones that I hated the most were like, if I write this control character to your terminal, like if it comes through your logger and it shows up in this terminal that hasn't been updated since 1996, It could possibly, like, it could possibly overwrite some characters. So then I'm able to hide stuff that's in the logs and I'm like, oh my God. And they're like, this is obviously most critical bug that there is. And you're like, no, please. This is, this is like not a critical bug, please. But people would haggle over that. But then when AI came around, they're like, ah, like we just get this flood of like low effort, you know, low-effort security issues because they could get free money, basically. Yeah. So, uh, the very first thing that they, like, IBB did was just shut off bounties. So they stopped paying bounties, and like, I gotta tell you, that really, uh, decreased the number of security reports that we get.

[01:10:58.04] - Robby
There's your solution. Just don't, just don't, just don't solicit them. Yeah, but I mean, that's—

[01:11:03.03] - Aaron
yeah, I know that's not It's not a good, it's not a good solution because like I want, I really want security researchers to get paid, right?

[01:11:10.11] - Robby
Yeah.

[01:11:10.22] - Aaron
But like, this is apparently not the way to do it. I mean, of course we also started using AI to process like process reports. I know people ask that. It's like, did you use it? Well, did you use AI to process them? We did. We do still do. I don't know. I don't have a good solution for it. I mean, it just feels like a damned if you do, damned if you don't type of situation. So.

[01:11:37.00] - Robby
Do you, have you seen much of an increase in just general PR contributions to the tools that you work on?

[01:11:44.09] - Aaron
I mean, we get a lot of AI contributions. To be honest, like people sending normal PRs using AI, like I don't really have a problem with that. That's fine. I think that's like whatever, more power to you. You did the thing like you wanted a feature, used, used whatever. I keep saying Claude. Claude's my favorite one, but I keep, I know there are others, but you know, you use Claude to do it. Seems good. Whatever. So I kind of like that.

[01:12:15.02] - Robby
Do you ask that they disclose that or is that even really that important to you?

[01:12:19.00] - Aaron
Uh, it's not really. Is it important to me? I don't think it's important to me.

[01:12:25.04] - Robby
Yeah.

[01:12:25.12] - Aaron
I mean, it's a, cause like when the, when the PR comes in, it's, if we accept the PR, it's now on us to maintain it. Like I don't ask, we can't ask anything from you. Mm-hmm. Right. Doesn't really have any impact per se.

[01:12:41.16] - Robby
Sure. I appreciate that take. I think I've, I've definitely talked to people across a lot of different, fall very differently on the spectrum. Do you feel like that would've been very different of a response 6 months ago? From you?

[01:12:54.11] - Aaron
Maybe. I don't know. I like, I don't, I didn't really think about it. Don't really think about it that much. Where it really does impact me is like, I don't care how other people use AI, but I care very deeply about how I personally use AI. Like I need to understand the code. I found like after that one experience with AI effing up real bad, I'm like, all right, Sorry, bud, you're now regulated or relegated to like, you know, stuff that I just don't want to do.

[01:13:29.23] - Robby
Which some might argue those could be the things that need the most attention.

[01:13:32.13] - Aaron
Sure.

[01:13:32.21] - Robby
Though, Rails 8. Yes.

[01:13:33.22] - Aaron
But I mean, the main thing is like, I personally need to understand every single line of code that is coming out of this thing. Like if I submit a patch, I need to understand all of it. Because I need to be able to defend it and explain it. And like, I ask that of people who send PRs to me, like, I'm going to ask questions about it. And if they can't answer the questions, it's probably not going to land. Like, the PR is not going to land, you know?

[01:13:59.10] - Robby
Yeah.

[01:13:59.14] - Aaron
But there's no judgment about whether or not they used AI. Like, if you used AI and you understand everything it did, great.

[01:14:06.16] - Robby
But it's hard to tell. Yeah. And that's an interesting— it's been an interesting thing, I think, navigating the last several months that I don't know where everybody's going to fall on this. Or some of the projects that I've been involved in, like it became the fact that we even said like, you could, can maybe disclose it. Like some people are like, I don't want to use your tool anymore because you're allowing AI to infect it. And I'm like, but it's, it's all the spectrums of, and everybody's.

[01:14:32.16] - Aaron
Yeah. I mean, you're not going to make it like nobody's going to be happy. So like, remember when, when, when Copilot first came around, it was like very, very much, you know, intelligent tab completion. It's like, well, is that, I mean, yeah, that's my example.

[01:14:46.05] - Robby
I always bring like, well, how do I know where and where, where does AI stop and start in some of the tooling that we're using? And it's just, is this an editor tool? I'm just, or if I'm just passing a GitHub issue, I'm like, hey, can you just submit me a PR for this? You can have it do that as well. You should probably review it, but then, but then some people will be like, well, I just have another bot review the PR and if it approves it, then great. We'll just ship stuff that way. And like, there are people trying to figure out how to make that work. With their organizations.

[01:15:11.04] - Aaron
And yeah, yeah, that, that part seems a little bit like somewhat risky to me at the moment. I'm kind of worried it will get into a situation where it's like bots reviewing bots reviewing bots, and then like we're gonna end up with a giant mess. It's gonna be— I think what we'll have is we'll have another like, um, oh, what is it, like a bunch of— you remember there were like tons of, um, software patterns coming out of like '90s and early 2000s where it's like, okay, design patterns. And then we have like all these names for things like the giant ball of mud and like all those different names. I think we're gonna have like— there's gonna be a new generation of shit code that's generated by AI. We're gonna have names for those, those things too.

[01:15:59.11] - Robby
We'll have to work on another episode where we can work on brainstorming names for these patterns then. That could be, that could be fun.

[01:16:05.02] - Aaron
Yeah, like, because like there's got to be a way to differentiate between a giant ball of mud that that was human-made, like a man-made one versus, versus an AI-made one. So funny I say man-made now because like that's not typically good. But now you said like a human-made—

[01:16:21.23] - Robby
It's not typically how mud is usually made either.

[01:16:24.08] - Aaron
Yeah, yeah. I've never made— I mean, I don't know.

[01:16:27.01] - Robby
Have you made— I guess I've made mud. Yeah, I poured water and dirt. Yeah, I guess so.

[01:16:31.03] - Aaron
I did that the other day. I was watering the garden.

[01:16:33.23] - Robby
Are we artificially creating mud?

[01:16:35.11] - Aaron
Yes.

[01:16:36.08] - Robby
Are we, is that, or I guess we are part of nature. Where does, where, hmm, let's get into the weeds on this one. I've kept you long enough, Aaron, but a couple of quick, quick questions for you. What areas of Ruby on Rails right now are you most excited about?

[01:16:54.10] - Aaron
What areas?

[01:16:55.19] - Robby
Specifically within the Rails framework itself.

[01:16:59.06] - Aaron
Oh my gosh. This is, this is a. Tough question for me. My favorite things are all like low-level stuff. Like I can't give you any, I can't give you any good high-level things, but one of the things I'm excited about is looking into router performance. That is very interesting to me and something that I've been poking at lately. So I'm hoping that we can ship some performance improvements to the Rails router. But again, it's like stuff you would, you don't know, like just upgrade and then you get it.

[01:17:33.00] - Robby
Yeah. Yeah.

[01:17:34.01] - Aaron
Right.

[01:17:34.09] - Robby
It's just magic stuff.

[01:17:35.05] - Aaron
Yeah.

[01:17:35.21] - Robby
Are you involved at all or see murmurs of like those that are working on things like for more tooling within Rails that will be useful with, yeah, with LLM tools?

[01:17:45.14] - Aaron
Yeah.

[01:17:45.23] - Robby
I think Rails Query, I think was a new thing that just got released or Rails 8.

[01:17:51.03] - Aaron
Uh, RubyDex is very cool, but I know it's not Rails, like it's not Rails. Specific. I really love the, really love the AI tooling that folks are coming up with. Like, anything that can help folks, like, get in and get developing on the application is very, very interesting and fun to me. I'm hoping that we get more features integrated, like, um, you know, Marco Roth, like, his stuff is so amazing. I, I want more of that stuff built into Rails 8. So, yeah, Herb is very, very cool. Extremely cool technology. I'm a huge fan.

[01:18:26.16] - Robby
So I'm with you on that one as well. I'm curious, Aaron, is there a part of Rails that you think the typical Ruby on Rails developer would benefit from going to look at the source code and acclimating themselves?

[01:18:39.12] - Aaron
Like, good question. Uh, I feel like I say good question a lot. Maybe I should say bad.

[01:18:47.14] - Robby
That was immediate, immediately a bad question. I thought actually you meant that it was a bad question.

[01:18:52.09] - Aaron
No, it's a good, it's a good question. I just I just feel like I'm saying that a lot.

[01:18:55.18] - Robby
Give them a homework assignment.

[01:18:57.03] - Aaron
Yeah, do it. Figure it out yourself. No, um, okay. I think like it depends on what you're interested in. So like, are you interested in the database? Go, you should dive into Active Record stuff. Are you interested in Vue stuff? You should dive into ActionView, uh, also ActionController. It really depends on what you're interested in. One of the things I did like when I first got started looking at Rails internals is like I'd be like, okay, how does LinkTo work? Like, how? And then I just went and read the source code for it. I am jealous of people getting started today, like, mainly because of AI stuff. Like, can you imagine? You're like, hey, I would like to get, I would like to get started understanding how Rails internals work. You could just go into Rails itself. With Claude or, or whoever and be like, tell me how LinkTo works. And then it's gonna walk you, it's gonna walk you through the freaking code. Incredible.

[01:19:57.07] - Robby
You could probably have it build a little tutorial that's custom tailored to your way of learning and learning things as well. And that, that could be kind of exciting.

[01:20:06.07] - Aaron
Like me, I had to do the slow, slow path. I'm like, how, how is this? Where is this defined? Where, where do I find this? Oh, nothing. Yeah.

[01:20:12.23] - Robby
Follow the method, follow the thing. Like, okay, goes to this and yes, this other method missing thing or what is this thing?

[01:20:18.06] - Aaron
Yes. Yes.

[01:20:19.05] - Robby
What does that even mean?

[01:20:20.04] - Aaron
And now today you got like a little buddy that's going to walk through it with you. So I like that.

[01:20:24.10] - Robby
Hold your hand.

[01:20:24.23] - Aaron
Yeah.

[01:20:25.17] - Robby
Do you have a technical book that you find yourself recommending recently to peers?

[01:20:30.08] - Aaron
I do. I'm very glad that you asked this question. I'm not sure if I'm supposed to. I think I can tell people there's a new book.

[01:20:40.13] - Robby
Oh.

[01:20:41.05] - Aaron
Well, not new. I recommend Ruby Under a Microscope. Pat is working on an update to it, like a v2, and I know this because I'm doing the technical review for it.

[01:20:51.15] - Robby
Ah.

[01:20:52.05] - Aaron
So I recommend that book when it comes out. I think it's in, I think they're gonna be putting in, it may already be in like a preview or whatever, so you can like read chapters from it and stuff. But I really recommend it because I think it is, is the best introduction to Ruby internals that you can get. Well, not even introduction, it's intro plus intermediate, probably advanced stuff too. Also, I'm reviewing it, so.

[01:21:22.04] - Robby
It's gonna be excellent.

[01:21:23.15] - Aaron
Yes, it's gotta be.

[01:21:24.10] - Robby
He's full of itches.

[01:21:26.09] - Aaron
Yes.

[01:21:27.18] - Robby
So Ruby Under the Microscope, and that's by, how do you pronounce his last name?

[01:21:30.23] - Aaron
Pat Shaughnessy, I think.

[01:21:32.11] - Robby
Shaughnessy, okay. I think. Who's publishing that? Is that self-published or?

[01:21:37.23] - Aaron
No, I think it's No Starch. I'm not sure.

[01:21:41.18] - Robby
Okay. I'll definitely include links to that in the show notes where people can check on that and find out when the next new version's coming.

[01:21:48.06] - Aaron
I have a second one if you're interested in, okay, I have a second one. This one's very, very advanced.

[01:21:53.07] - Robby
We're outta time, Aaron.

[01:21:54.12] - Aaron
Oh shoot.

[01:21:55.00] - Robby
Okay. All right.

[01:21:56.07] - Aaron
Go ahead. So there's, I have a second one, but this one's very advanced. So if you want to learn about JIT compilers or any compilers, I recommend a book called Engineering a Compiler. And it's very good. It's got a lot of the techniques that we use in our, in ZJIT in it. So if you want to learn how it works, there you go.

[01:22:17.01] - Robby
Excellent. I'll definitely include links to that, both of those books in the show notes for listeners. And where can listeners best follow your thoughts and ruminations about Ruby, Rails 8, and software engineering online?

[01:22:26.12] - Aaron
Uh, you can follow me on Bluesky, Tenderlove, uh, also my, I'm trying to I make more blog posts at tenderlovemaking.com.

[01:22:34.18] - Robby
Excellent. I'll include links for all that as well. And with that, thank you so much for stopping by to talk shop with us, Aaron.

[01:22:40.01] - Aaron
Yes. Thank you, Robby. It was a pleasure.

[01:22:43.03] - Robby
It's been such a delight to get to, get to see you and hopefully get to see you again at an upcoming conference or something.

[01:22:48.04] - Aaron
Yes, of course.

[01:22:52.03] - Robby
That's it for this episode of On Rails 8. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.