Hey, welcome back to another Ruby Dev Summit interview. Today, I'm talking to Jeremy Evans. Jeremy is the author of several gems that you may have used or heard of, such as the sequel gem, which is a sequel database ORM type library. You've also got Rota, which is a web framework built on Rack. And he's the author of Polished Ruby Programming, which we covered on Ruby Rogues and maybe we'll put a link in the show notes to that. But yeah, anyway, he contributes to all kinds of stuff in
the Ruby ecosystem and I'm super excited to get his opinion. Thanks for coming, Jeremy, Thank you very much for having me. All Right, I'm gonna kick us off with a question I've started every other interview with, and that is what is the future of Ruby? That's an interesting question. Mostly I see Ruby sort of staying on the same path it is now. I
don't see major changes happening in the language, right. I mean, if you ever listened to one of Mattz's recent keynotes, he always talks about stability. He talks about change too. He definitely wants Ruby to change and be updated. You don't want to be like static and not changing. But I don't anticipate significant, like breaking changes, even stuff that's i'd say unlikely to
affect most people. Anything backwards incompatible generally get significant pushback these days. One thing I do see a changing is really continuing to get faster, mostly from wy GIT. So I think a big improvement in three two over three one,
big improvement in three three over three two. I would expect three four to have big improvement as well, I think eventually, or they're going to get to the point where it's not going to be as improving as fast because obviously they're trying to do all the low end, low hanging fruit first, and still expect another release or two to have significant performance improvements, you know,
across the board were all apps. I mean, I think they're pretty much already there with three three, but I would I would expect continual improvements for most apps, at least for the next couple of releases while they continue to improve things. Right, So let's back up on some of this. So you talked about stability first and continuing on the same course that's on.
I think that's a pretty safe bet. But is there anything in particular that you see that makes you think that or you know, mostly just obviously Matt's if you ever heard him talk, he's going to be the leader of Ruby. I think for the next few years at least. I mean, he has talked a little bit about retirement, but it's probably a few years off. I mean when I talk about the future of Ruby, I try out
to do like too far in the future. My future is like, yeah, five years from now, Like where where's the room going to be? Five years from now? It's where I'm thinking when you're asking about the future of Ruby right now, and again, Matts is conservative in terms of the features he accepts. Uh. Obviously there was a lot of breakage one eight to one nine, breakage two seven to three to oho, though substantially less
than one eight to one nine. And I don't anticipate there being significant changes even as much as two seven to three to zero in the future, I mean, not right next five years at least. Yep, absolutely so, I guess moving on to the other point you made about Uh, I was going to say productivity, but it's performance. So looking at the performance games that we've gotten, yeah, I think the big one that we've seen in three two to three three has mostly been that wygit is turned on by default,
and so people are seeing some of that magic. Yeah, well it's not technically on by default, Like even if Ruby's compiled by default, why jet will not be enabled by default on the moment I thought it was. Now one of the big things in three three is that you can turn wyget on at runtime. So previously, if you were using Ruby, you'd have to specify like dash dash wygit or some environment variable to have wiget turned on.
But now you can run Ruby wigit enable at run time. Even if as long as Ruby is built with wigit support, which almost everyone is going to do if they're on something that wiget supports, you can turn it on at runtime, which means that web frameworks like Rails and potentially others will make it so it's on. It'll be on by default for most reviewsers, even though they're not manually configuring it. Because I think Rails eight the plan is
to have wiget enabled by default. I don't know if that makes sense, want it. I'm used Rails a lot, but you know, recently, but I think that's I think it is. The planet leaks for Rails eight might even already be in Rail seven point. I don't know. Yeah, I wouldn't be shocked if well, usually what happens is is that you'll get some level of adoption, you know, in the current version of Rails, and then yeah, big changes like that will come in the next version,
so it'll it might prefer it, but it probably won't require it. Yeah, that makes sense, and Rails definitely won't require it. It'll only enable it if it's supported, because it's only supported three three currently. Yeah,
Rails. I think if the Rails at eight is aiming for Rails or Ruby three to one support, so it'll be something like if you're on Ruby three three and it supports wige it enable, it will enable it for you because wyg it is definitely a trade off, but it's trade off most people are gonna want to make. I mean, you're giving up some memory for significantly
better performance a really low memory system. You might not want to enable it, but I would say the majority of ruboy applications are gonna want to enable it. Yeah, I would imagine. So are you seeing the same kind of thing with like Rota or some of the other projects that you work on. Yeah, I I've tested wygit on my own apps and terms of my production apps at work. I haven't turned them mind yet because generally we're very
conservative here government. It's uh, it will probably be using Ruby three three until June. I would guess usually do it after we upgrade operating systems, so language upgrade sort of comes out for an operating system upgrade, which we do every six months. So well, probably won't be using Rube three three until June. But yes, certainly when we're using I plan to have why git enabled in my testing at home. On my personal applications. It's fine.
It just takes more memory, not super not a ton more memory, and does give better performance, So there's really not a good reason to disable it unless you're very low on the amount of memory you can use, right, that makes sense. Are there any other things coming in in the feudure in you know, in Ruby? There in some of the things that you're working on that you're excited about. I'm certainly so excited about the work I've
been doing to eliminate allocations. So a lot of review people users, emerging people have using for Ruby wild don't aren't aware that Ruby will allocate a significant number of objects internally in cases where you would not expect it to. Like.
One of the things I worked on just last week was allocating if you just like have a literal array that's very large, that that does not all static numbers for example, as like method calls and things, Ruby will break it into small blocks to avoid stack overflow, and it can end up generating hundreds of arrays. If you're you're a literal arrays large enough, Ruby will internally generate like hundreds of arrays interesting them together. And I've been working on
things where that sort of eliminates the unnecessary allocations. Some of that work was in three three. A lot of work got merged into after three three, so it'll be in three four. One of the things I was working on I think is really cool is Ruby three one had the ability to have anonymous
splats so you can do deaf method name star Comma starstar for example. That's stars for all positional arguments and star stars for all keyword arguments, and I produced it wasn't allowed by Ruby. You couldn't do this in a method previously in Ruby, so that syntax was added mostly for easier use. In Ruby. You can just if you don't need to name it you can just leave
it unnamed and you can still use it you're calling methods. One of the things that I figured out that this allows us to do is eliminate unnecessary array allocations and hash allocations. Because if you have a named method argument, you can access it, you can modify it, you have to allocate a new array for it. But if you have an unnamed argument, there's no way to directly access it. You can only pass it as a splat either positional
splatter keyword splatter on another method. Therefore, you can skip allocated the array necessarily. So this can make it so if you have chains where you're like forwarding arguments from one method to another, if you don't need to access the arguments, you can actually skip doing that and say multiple rays and method chains, and I know those especially rails, and certainly a lot of other Web applications and frameworks tend to like delegate methods to other methods, delegate arguments to
other methods if they switch to using anonymous splats instead of name splats. In cases where they can, significant number of allocations can be eliminated. So I'm really interested to see where people take that. It's something that right now doesn't really improve performance for most applications because most people haven't switched to using these anonymous splats, but this gives a performance reason to do it, So I'm excited
to see what happens in the future with that. Right, So with the fewer allocations, we're talking about memory performance, not necessarily say the speed of the application or does it diffend It improves speed, So obviously less allocations makes it faster, but also makes it less garbage to collect your garbage collect Less works run faster, So those are really the two reasons to avoid it.
Ruby itself. One of the reasons that Ruby is slow is in a lot of cases you're allocating objects and just object allocation is not that fast a lot of like you're running an SQL qureer, object allocation is minimal compared to that, but compared to adding two numbers, it's significantly more involved and makes things slower. One of the fastest like if you don't know how to optimize your code, like let's say you run a profile on it and nothing seems to
be like jumping out of you is what to optimize. Finding ways to reduce allocations can dramatically speed things up. I mean it often doesn't show up. I think some profilers might be able to take garbage collection time into account, but if they don't specifically target garbage collection, sort of garbage collection sort of
spread out over everything. And the only good optimize it is sort of like to figure out where allocating things sort of reduce the number of allocations, right, the only thing you can do, But it's one of the best things you can do if you're not sure where to improve something. If you have something that allocates a lot, reducing their allocations one of the best ways to
optimize it. So is the work you've done in allowing us as you know, kind of the I don't want to call us like normis or something, but you know, the people who aren't deep into the Ruby core code.
Are you working to allow us to do this or are you finding places where you can do this where we'll see the performance gained without actually having to modify the way we write code or correct So the idea with the optimizations I've been doing is to the Ruby interpreter or the virtual machine changing adding instructions, changing how instructions are implemented. A lot of changes are in the compiler or changing which instructions are you used, and the idea is no, you won't need
to modify any of your Ruby code. But Ruby code previously allocated a lot of objects, or at least some objects, like for each method call, the allocating objects even if you didn't have an object, like you're not creating a ray, but real be sort of creating or internally. So my goal. The thing is you can't because of the way Ruby works, like flat parameters, keywords, splat parameters, there's no way to completely eliminate these implicit
allocations. You can't do it. It's just required by the language. But we can make it. My goal is to make it so that any method call will not allocate more than one array and more than one hash. That's rightly so because previously, I mean, you could call a method and depending on what you're doing, be like five six objects allocated for no reason. I mean not no reason. There's reasons it was doing it, but it wasn't optimized to remove them. So that's a lot of what I've been working
on is to remove them. Yeah, and it seems like when I talk to people who say use go or something like that, that's one of the things that often tout is, well, you know, I rewrote my app and Go and I could you know, I reduced the number of servers I had by like two or something. And so this this is a step toward
that. Where as we you know, we make it do less garbage collection, we spend less time doing the allocations, and we spend less memory overall doing this stuff and causing the garbage collection to have to happen more frequently, we may be able to consolidate our hardware usage or at least make it more performant that way as well. Right, Yeah, I mean, certainly goal
go is always going to be faster compiled on be faster than rebe. But the really question is, you know, straight off, Ruby generally is going to be more productive than those languages. Yes, some people may not think that. Some people don't. Some people I can really rely on static types. I've heard some people's feelings saying that. But yeah, Ruby has like static typing support, but I haven't used it. I can tell you whether
it's good or not. It's certainly not gonna be as good to ask like a language that's built on stating types like Go or you know, Java. But in general, people think of Ruby is a very productive language, and I think I think it is, but yeah, one of the trade offs you make is that performance is not going to be as good. So again, it depends on what you're trying to optimize for. You're trying to optimize for develop productivity, or you try trying to optimize for run time performance.
I think Ruby it's obviously run time performance is no. We try to make it better. As we're working on RUB, we trying to make it as fast as we can, but it's it's never going to be as fast as like SEE or rust or go. Even so again, if you have super big performance needs, probably not a good idea to use RUB for those M Yeah makes sense. I just still I really love the different optimizations that are coming in. You mentioned that you haven't done a lot with the typing.
We talked to Soro Matsumoto, who's working on URBS, talk to a few people about related things, trying to get the guy behind type proft. I can't remember his name on the summit moment Amazon. Yeah, So anyway, we're working on a lot of that, and I've talked to people on a lot of these different points, like how they work under the hood. We also had Samuel Williams come on and talk about a sink and falcon some currency stuff, and so, I mean, there's all kinds of stuff that's so
exciting just to see it. Yeah, that's the things you ask like people at the future of Ruby is. And then there's Ruby is so large that people have YEA dramatically different things of what they're thinking about, even because of how I mean different things that were going on in Ruby, and we have people focusing just on the parser, or just people focusing just on the expression engine, on people focusing just on the virtual machine, or a lot of
people a lot of people focusing just on wy git. And then one of the big things I think is in three four, probably in three four, even if it's not the default, will be the new parts, which is Prism. I'm sure if you've talked to Kevin Newton about that, but him and his team are working on that. So the goal being to basically have Prism is the default parser for all the Ruby implementations be is the long term
goal. It's not there yet. The parser part is fine, but taking Prism and making bringing into Ruby as the default parser requires in the grit rate you change the compiler you're using. The Prism parser doesn't use the same format that the existing what's called pars dot y parser uses, so they've been working extensively on getting the Prism compiler to basically compile Ruby code the same way the
existing parser does. And that's very challenging because Ruby, i think, more than any other language, goes out of its way to be flexible in terms of the parsing, which makes it extreme, makes the parts are extremely complex, and which also results in the compiler being very complex as well. Yeah, to deal with all the different you know, things that can happen in
parsing. A lot of this is just because things are who would say, are not incredibly well factored internally, Like often you're making the same change in multiple places. A lot of it for performance reasons, so like you know, you try to it's not like when you call a method, it like splits up the path. The method takes into like a large number of different paths, each separately optimized for performance, which is good for performance, but
for maintenance makes things significantly more challenged. Yeah, that makes sense. Yeah, I've been having some back and forth with Kevin, so yeah, super excited to see where that leads us. As far as you know, we've been talking kind of about Ruby and about some of the technical pieces of the you know, whether it's the parser, the VM or you know, some of these things with memory management and performance. Where do you see things going
kind of in the broader world of Ruby. Right, So now we're talking about like rack, which I know you've contributed to, or Rota, or you know, building apps, you know, whether it's Rails or whether it's something else or who whatever. Yeah, in terms of the future Ruby, I think most people are still going to be using Rails. I mean, Rails is so popular. I mean I don't use Rails, but I mean
so many other people do. I don't expect that to change in the near future, if we're in the far future even right, But Rails will also be like most people's reason to use Ruby. It's okay, I mean it brings a lot of people in. I started using Ruby because I was, you know, originally doing like Python and PHP before I got into Ruby, and right that got me into Ruby was Rails. So it's not like Rails
brings people into the Ruby committee. Tons of people. A lot of people that are in Ruby would not be in Ruby if it wasn't for Rails. So rather think Ruby itself owes rails quite a bit just for bringing people in and broadening the community. So I think a lot of even if you don't use rails, you benefit from the larger Ruby community that Rails brings in. See, I don't expect that to change, uh. In terms of my libraries like Seql, road U, roade off other things like that they get
updated. I mean Sequel gets updated and Rota gets updated every month. Every
month. There's new features, new things to try out. But there's nothing I wouldn't say there's like huge changes on the rise, and like a lot of things are Rails adding or like what sort of say things you would think about sort of being external to the framework, and they're sort of bringing them in because what they want rails to be, like you know, you've use rails, you're using you know, used to be like just the object relational
mapper and sort of framework part to build things. And they've been expanding it. I mean yeah in many years. I mean you were talking about they built in the you know, document upload thing, active storage for bringing in like actually mailt across kind of emails now they have like solid queue and a whole bunch of things they're adding that are sort of outside the core framework, but they're building around it. So again the idea is if you run rails,
more people are running are sort of the same thing. That's one of the things people like about Rails is like, I've already worked on one Rails app. I had worked on you know, everyone else's Rails app, which is not exactly true, but it is. It is pretty true that, you know, rails apps tend to be very similar. That's one of the
reasons that I don't even try to do that with RODA. Roda is basically like, here's a minimal framework, here's a whole bunch of plug ins, sort of build exactly what you need, which is definitely percent not what Rails is. Rails is they called oma cat, which is like, you know, this out is deal with Italy, build exactly what you need, what's best for you, and that's there's a double edged sword. Sometimes if you're
comfortable with that, it's great, it's exactly what you want. But certainly if you look at one road to app and differ road to app, they're not necessarily going to be as similar. As to rails apps, again, with a larger development team, you're hiring a bunch of other people that already know it. It's very helpful to have Rails for that. If that's not the situation you're in and you're comfortable building everything yourself, and then like RODA
makes a lot more sense. It's a lot simpler, a lot easier to understand. There's less i'd say churn when upgrading things like that, so it's a trade off. And again for a lot of people, the trade off the Rails makes as good, and that's that's great. I'm not one of the people like I want to take over the world and everyone should use my software. Roada is very good for me. It's very good for what it does. A lot of people use it now, but it's never going to
be as popular as Rails. I'm completely comfortable with that. Yeah, it's Equel and Active Record. I think the sequel is technically a lot better but Rail, but Active Record has been significantly improving in recent versions too. It's i'd say, caught up a lot of the way from where it was, you know, ten fifteen years ago. It's I think still I still think
the sequel is better. Technically, there are problems that I think act the record has that sequel solves still, but it's much closer now than it was ten or fifteen years ago. Right, So, so do you see any advance was coming in Ruby or changes in the community that are going to affect the direction you head in or do you think things like you said of Ruby are just going to kind of continue the way they're going. Certainly language is
going to continue. One of the things I'm quite excited about myself is to see, like certainly when COVID hit and the Roby community in terms of like conferences meetups almost immediately shut down Dor to covid. It's not unique to RUBE. That's i'd say, across the board from most places. Yeah, I am very excited to see, especially this year, just tons like it was
in the late twenty tens, tons of reconferences coming back. You know, Like there's like twenty conferences already you know this year that are scheduled and there's probably going to be more, which is really exciting from a community basis. If you want to get involved or meet people in the community, it's gonna be much easier now than it was like two or three years ago. She's something I'm excited about as well. Yeah, I had that conversation with Amanda
Parino from the Rails Foundation. She's the director of the Foundation, and it was interesting just kind of from that community standpoint, right, just talking about some of the things that are coming back, maybe some of the hiccups or struggles with maybe having as many of the meetups and things that we used to have, but still we're seeing a lot of that get revived and it's very
exciting. Yeah, I'm definitely excited about that. Yeah. Is there anything else that you're working on or things you see out there in the community at large that you're excited about or uh No, not really. I mean I haven't had as much time to work on Ruby recently. I've had been much busier than I normally am and I probably continued this year and maybe really not sure, so I probably don't be as involved as I was. I mean
I was also very busy last year. But right, hopefully any couple of years I'll be able to get back more into, you know, contributing more more like I used to, you know, from like twenty nineteen at like twenty twenty two. So I'm hoping to do that, but it's probably I'm gonna say a year eighteen months away before I can only get more involved. I still I still gonna be helping out. You know, every one thought we would be contributing stuff, but it won't be the frequency that I would
prefer to be at. Cool. Well, we still have a few minutes. Do you want to talk about your book for a second. Let people know what it's about. Sure, so Polish reprogramming. It's different than most of other review books. It assumes you already know review fairly well, and it sort of talks about trade offs to make when you're designing applications and libraries designed for intermedia or a revie programmer sort of to reach the next level.
It still sells fairly well. I mean certainly sales have dropped off since it was released till I think two and a half years ago. It still sells decently. I get every week your books sold this much. So, uh, it's still doing well. I'm happy about it. I'm not eager to write a follow up anytime soon, because I think we talked about that doing
the regrows thing. Writing a book is this incredible about of work, and I don't think I want to get involved in that, uh, not anytime soon at least, and I'm not eager to get back and back in the saddle. Yeah, I'm I'm I'm I'm happy, happy, it's doing well, and it's still seems to me I still see places where it's not recommended for, you know, the audiences intended form, which is great. Cool. All right, well, I'll go ahead and wrap us up. Then
thank you again for coming. Going all right, well, until next time, folks,