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,