WEBVTT

1
00:00:00.120 --> 00:00:05.040
Hey, welcome back to another Ruby
Dev Summit interview. Today, I'm talking

2
00:00:05.080 --> 00:00:10.800
to Jeremy Evans. Jeremy is the
author of several gems that you may have

3
00:00:10.919 --> 00:00:15.679
used or heard of, such as
the sequel gem, which is a sequel

4
00:00:15.800 --> 00:00:20.039
database ORM type library. You've also
got Rota, which is a web framework

5
00:00:20.039 --> 00:00:25.079
built on Rack. And he's the
author of Polished Ruby Programming, which we

6
00:00:25.120 --> 00:00:27.960
covered on Ruby Rogues and maybe we'll
put a link in the show notes to

7
00:00:28.000 --> 00:00:32.240
that. But yeah, anyway,
he contributes to all kinds of stuff in

8
00:00:32.240 --> 00:00:36.759
the Ruby ecosystem and I'm super excited
to get his opinion. Thanks for coming,

9
00:00:36.840 --> 00:00:40.240
Jeremy, Thank you very much for
having me. All Right, I'm

10
00:00:40.280 --> 00:00:43.640
gonna kick us off with a question
I've started every other interview with, and

11
00:00:43.679 --> 00:00:48.560
that is what is the future of
Ruby? That's an interesting question. Mostly

12
00:00:48.640 --> 00:00:51.200
I see Ruby sort of staying on
the same path it is now. I

13
00:00:51.200 --> 00:00:56.640
don't see major changes happening in the
language, right. I mean, if

14
00:00:56.640 --> 00:01:02.320
you ever listened to one of Mattz's
recent keynotes, he always talks about stability.

15
00:01:02.320 --> 00:01:06.280
He talks about change too. He
definitely wants Ruby to change and be

16
00:01:06.359 --> 00:01:10.120
updated. You don't want to be
like static and not changing. But I

17
00:01:10.159 --> 00:01:17.640
don't anticipate significant, like breaking changes, even stuff that's i'd say unlikely to

18
00:01:17.680 --> 00:01:26.560
affect most people. Anything backwards incompatible
generally get significant pushback these days. One

19
00:01:26.560 --> 00:01:30.480
thing I do see a changing is
really continuing to get faster, mostly from

20
00:01:30.560 --> 00:01:36.599
wy GIT. So I think a
big improvement in three two over three one,

21
00:01:37.239 --> 00:01:41.799
big improvement in three three over three
two. I would expect three four

22
00:01:41.879 --> 00:01:46.280
to have big improvement as well,
I think eventually, or they're going to

23
00:01:46.280 --> 00:01:49.879
get to the point where it's not
going to be as improving as fast because

24
00:01:49.879 --> 00:01:53.599
obviously they're trying to do all the
low end, low hanging fruit first,

25
00:01:53.439 --> 00:02:00.040
and still expect another release or two
to have significant performance improvements, you know,

26
00:02:01.519 --> 00:02:05.359
across the board were all apps.
I mean, I think they're pretty

27
00:02:05.400 --> 00:02:08.680
much already there with three three,
but I would I would expect continual improvements

28
00:02:09.159 --> 00:02:14.560
for most apps, at least for
the next couple of releases while they continue

29
00:02:14.599 --> 00:02:17.719
to improve things. Right, So
let's back up on some of this.

30
00:02:17.800 --> 00:02:23.479
So you talked about stability first and
continuing on the same course that's on.

31
00:02:23.800 --> 00:02:29.120
I think that's a pretty safe bet. But is there anything in particular that

32
00:02:29.159 --> 00:02:35.280
you see that makes you think that
or you know, mostly just obviously Matt's

33
00:02:35.280 --> 00:02:38.960
if you ever heard him talk,
he's going to be the leader of Ruby.

34
00:02:38.960 --> 00:02:39.639
I think for the next few years
at least. I mean, he

35
00:02:39.639 --> 00:02:44.639
has talked a little bit about retirement, but it's probably a few years off.

36
00:02:45.560 --> 00:02:46.759
I mean when I talk about the
future of Ruby, I try out

37
00:02:46.759 --> 00:02:51.319
to do like too far in the
future. My future is like, yeah,

38
00:02:51.360 --> 00:02:53.759
five years from now, Like where
where's the room going to be?

39
00:02:53.800 --> 00:02:57.199
Five years from now? It's where
I'm thinking when you're asking about the future

40
00:02:57.240 --> 00:03:00.840
of Ruby right now, and again, Matts is conservative in terms of the

41
00:03:00.840 --> 00:03:05.919
features he accepts. Uh. Obviously
there was a lot of breakage one eight

42
00:03:05.960 --> 00:03:09.560
to one nine, breakage two seven
to three to oho, though substantially less

43
00:03:09.560 --> 00:03:16.719
than one eight to one nine.
And I don't anticipate there being significant changes

44
00:03:16.840 --> 00:03:21.080
even as much as two seven to
three to zero in the future, I

45
00:03:21.080 --> 00:03:25.639
mean, not right next five years
at least. Yep, absolutely so,

46
00:03:25.879 --> 00:03:30.759
I guess moving on to the other
point you made about Uh, I was

47
00:03:30.800 --> 00:03:36.400
going to say productivity, but it's
performance. So looking at the performance games

48
00:03:36.400 --> 00:03:39.199
that we've gotten, yeah, I
think the big one that we've seen in

49
00:03:39.280 --> 00:03:45.560
three two to three three has mostly
been that wygit is turned on by default,

50
00:03:45.840 --> 00:03:51.360
and so people are seeing some of
that magic. Yeah, well it's

51
00:03:51.360 --> 00:03:54.919
not technically on by default, Like
even if Ruby's compiled by default, why

52
00:03:55.000 --> 00:03:59.280
jet will not be enabled by default
on the moment I thought it was.

53
00:04:00.039 --> 00:04:03.120
Now one of the big things in
three three is that you can turn wyget

54
00:04:03.159 --> 00:04:06.759
on at runtime. So previously,
if you were using Ruby, you'd have

55
00:04:06.840 --> 00:04:12.479
to specify like dash dash wygit or
some environment variable to have wiget turned on.

56
00:04:12.560 --> 00:04:15.680
But now you can run Ruby wigit
enable at run time. Even if

57
00:04:15.720 --> 00:04:19.480
as long as Ruby is built with
wigit support, which almost everyone is going

58
00:04:19.519 --> 00:04:24.680
to do if they're on something that
wiget supports, you can turn it on

59
00:04:24.720 --> 00:04:30.839
at runtime, which means that web
frameworks like Rails and potentially others will make

60
00:04:30.879 --> 00:04:33.199
it so it's on. It'll be
on by default for most reviewsers, even

61
00:04:33.199 --> 00:04:38.439
though they're not manually configuring it.
Because I think Rails eight the plan is

62
00:04:38.439 --> 00:04:41.639
to have wiget enabled by default.
I don't know if that makes sense,

63
00:04:41.759 --> 00:04:45.759
want it. I'm used Rails a
lot, but you know, recently,

64
00:04:46.480 --> 00:04:47.759
but I think that's I think it
is. The planet leaks for Rails eight

65
00:04:47.839 --> 00:04:51.560
might even already be in Rail seven
point. I don't know. Yeah,

66
00:04:51.560 --> 00:04:59.800
I wouldn't be shocked if well,
usually what happens is is that you'll get

67
00:05:00.120 --> 00:05:02.519
some level of adoption, you know, in the current version of Rails,

68
00:05:02.560 --> 00:05:04.959
and then yeah, big changes like
that will come in the next version,

69
00:05:05.000 --> 00:05:10.639
so it'll it might prefer it,
but it probably won't require it. Yeah,

70
00:05:10.639 --> 00:05:15.079
that makes sense, and Rails definitely
won't require it. It'll only enable

71
00:05:15.120 --> 00:05:18.120
it if it's supported, because it's
only supported three three currently. Yeah,

72
00:05:18.199 --> 00:05:21.560
Rails. I think if the Rails
at eight is aiming for Rails or Ruby

73
00:05:21.560 --> 00:05:25.759
three to one support, so it'll
be something like if you're on Ruby three

74
00:05:25.800 --> 00:05:29.519
three and it supports wige it enable, it will enable it for you because

75
00:05:30.720 --> 00:05:32.720
wyg it is definitely a trade off, but it's trade off most people are

76
00:05:32.759 --> 00:05:38.000
gonna want to make. I mean, you're giving up some memory for significantly

77
00:05:38.040 --> 00:05:42.560
better performance a really low memory system. You might not want to enable it,

78
00:05:43.120 --> 00:05:46.319
but I would say the majority of
ruboy applications are gonna want to enable

79
00:05:46.319 --> 00:05:50.560
it. Yeah, I would imagine. So are you seeing the same kind

80
00:05:50.600 --> 00:05:54.800
of thing with like Rota or some
of the other projects that you work on.

81
00:05:55.319 --> 00:05:59.519
Yeah, I I've tested wygit on
my own apps and terms of my

82
00:05:59.519 --> 00:06:03.199
production apps at work. I haven't
turned them mind yet because generally we're very

83
00:06:03.199 --> 00:06:08.319
conservative here government. It's uh,
it will probably be using Ruby three three

84
00:06:08.439 --> 00:06:13.120
until June. I would guess usually
do it after we upgrade operating systems,

85
00:06:13.160 --> 00:06:16.560
so language upgrade sort of comes out
for an operating system upgrade, which we

86
00:06:16.639 --> 00:06:19.240
do every six months. So well, probably won't be using Rube three three

87
00:06:19.360 --> 00:06:23.959
until June. But yes, certainly
when we're using I plan to have why

88
00:06:24.040 --> 00:06:28.639
git enabled in my testing at home. On my personal applications. It's fine.

89
00:06:28.639 --> 00:06:31.600
It just takes more memory, not
super not a ton more memory,

90
00:06:32.000 --> 00:06:36.319
and does give better performance, So
there's really not a good reason to disable

91
00:06:36.319 --> 00:06:42.079
it unless you're very low on the
amount of memory you can use, right,

92
00:06:43.079 --> 00:06:47.759
that makes sense. Are there any
other things coming in in the feudure

93
00:06:47.759 --> 00:06:50.399
in you know, in Ruby?
There in some of the things that you're

94
00:06:50.439 --> 00:06:54.720
working on that you're excited about.
I'm certainly so excited about the work I've

95
00:06:54.720 --> 00:07:00.519
been doing to eliminate allocations. So
a lot of review people users, emerging

96
00:07:00.680 --> 00:07:05.279
people have using for Ruby wild don't
aren't aware that Ruby will allocate a significant

97
00:07:05.319 --> 00:07:11.279
number of objects internally in cases where
you would not expect it to. Like.

98
00:07:11.920 --> 00:07:16.439
One of the things I worked on
just last week was allocating if you

99
00:07:16.560 --> 00:07:20.519
just like have a literal array that's
very large, that that does not all

100
00:07:20.560 --> 00:07:26.519
static numbers for example, as like
method calls and things, Ruby will break

101
00:07:26.560 --> 00:07:31.040
it into small blocks to avoid stack
overflow, and it can end up generating

102
00:07:31.120 --> 00:07:34.680
hundreds of arrays. If you're you're
a literal arrays large enough, Ruby will

103
00:07:34.720 --> 00:07:42.120
internally generate like hundreds of arrays interesting
them together. And I've been working on

104
00:07:42.160 --> 00:07:46.639
things where that sort of eliminates the
unnecessary allocations. Some of that work was

105
00:07:46.680 --> 00:07:53.439
in three three. A lot of
work got merged into after three three,

106
00:07:53.480 --> 00:07:56.680
so it'll be in three four.
One of the things I was working on

107
00:07:56.680 --> 00:08:01.240
I think is really cool is Ruby
three one had the ability to have anonymous

108
00:08:01.240 --> 00:08:09.680
splats so you can do deaf method
name star Comma starstar for example. That's

109
00:08:09.759 --> 00:08:15.079
stars for all positional arguments and star
stars for all keyword arguments, and I

110
00:08:15.160 --> 00:08:18.839
produced it wasn't allowed by Ruby.
You couldn't do this in a method previously

111
00:08:18.879 --> 00:08:24.800
in Ruby, so that syntax was
added mostly for easier use. In Ruby.

112
00:08:24.800 --> 00:08:26.800
You can just if you don't need
to name it you can just leave

113
00:08:26.839 --> 00:08:33.120
it unnamed and you can still use
it you're calling methods. One of the

114
00:08:33.120 --> 00:08:37.159
things that I figured out that this
allows us to do is eliminate unnecessary array

115
00:08:37.200 --> 00:08:43.720
allocations and hash allocations. Because if
you have a named method argument, you

116
00:08:43.759 --> 00:08:46.000
can access it, you can modify
it, you have to allocate a new

117
00:08:46.120 --> 00:08:50.480
array for it. But if you
have an unnamed argument, there's no way

118
00:08:50.600 --> 00:08:56.000
to directly access it. You can
only pass it as a splat either positional

119
00:08:56.000 --> 00:09:00.440
splatter keyword splatter on another method.
Therefore, you can skip allocated the array

120
00:09:00.559 --> 00:09:03.000
necessarily. So this can make it
so if you have chains where you're like

121
00:09:03.080 --> 00:09:07.679
forwarding arguments from one method to another, if you don't need to access the

122
00:09:07.759 --> 00:09:13.559
arguments, you can actually skip doing
that and say multiple rays and method chains,

123
00:09:13.120 --> 00:09:16.039
and I know those especially rails,
and certainly a lot of other Web

124
00:09:16.080 --> 00:09:22.799
applications and frameworks tend to like delegate
methods to other methods, delegate arguments to

125
00:09:22.799 --> 00:09:28.759
other methods if they switch to using
anonymous splats instead of name splats. In

126
00:09:28.799 --> 00:09:35.639
cases where they can, significant number
of allocations can be eliminated. So I'm

127
00:09:35.679 --> 00:09:39.480
really interested to see where people take
that. It's something that right now doesn't

128
00:09:39.919 --> 00:09:46.240
really improve performance for most applications because
most people haven't switched to using these anonymous

129
00:09:46.240 --> 00:09:50.519
splats, but this gives a performance
reason to do it, So I'm excited

130
00:09:50.559 --> 00:09:54.320
to see what happens in the future
with that. Right, So with the

131
00:09:54.360 --> 00:09:58.679
fewer allocations, we're talking about memory
performance, not necessarily say the speed of

132
00:09:58.679 --> 00:10:01.799
the application or does it diffend It
improves speed, So obviously less allocations makes

133
00:10:01.840 --> 00:10:05.600
it faster, but also makes it
less garbage to collect your garbage collect Less

134
00:10:05.600 --> 00:10:09.840
works run faster, So those are
really the two reasons to avoid it.

135
00:10:11.840 --> 00:10:15.360
Ruby itself. One of the reasons
that Ruby is slow is in a lot

136
00:10:15.360 --> 00:10:20.440
of cases you're allocating objects and just
object allocation is not that fast a lot

137
00:10:20.480 --> 00:10:24.919
of like you're running an SQL qureer, object allocation is minimal compared to that,

138
00:10:24.360 --> 00:10:30.679
but compared to adding two numbers,
it's significantly more involved and makes things

139
00:10:30.720 --> 00:10:33.879
slower. One of the fastest like
if you don't know how to optimize your

140
00:10:33.919 --> 00:10:37.000
code, like let's say you run
a profile on it and nothing seems to

141
00:10:37.039 --> 00:10:39.679
be like jumping out of you is
what to optimize. Finding ways to reduce

142
00:10:39.759 --> 00:10:46.559
allocations can dramatically speed things up.
I mean it often doesn't show up.

143
00:10:48.720 --> 00:10:52.440
I think some profilers might be able
to take garbage collection time into account,

144
00:10:52.639 --> 00:10:56.600
but if they don't specifically target garbage
collection, sort of garbage collection sort of

145
00:10:56.639 --> 00:11:01.480
spread out over everything. And the
only good optimize it is sort of like

146
00:11:01.519 --> 00:11:05.679
to figure out where allocating things sort
of reduce the number of allocations, right,

147
00:11:05.919 --> 00:11:07.159
the only thing you can do,
But it's one of the best things

148
00:11:07.159 --> 00:11:13.080
you can do if you're not sure
where to improve something. If you have

149
00:11:13.080 --> 00:11:16.200
something that allocates a lot, reducing
their allocations one of the best ways to

150
00:11:16.240 --> 00:11:22.519
optimize it. So is the work
you've done in allowing us as you know,

151
00:11:22.639 --> 00:11:26.399
kind of the I don't want to
call us like normis or something,

152
00:11:26.399 --> 00:11:30.879
but you know, the people who
aren't deep into the Ruby core code.

153
00:11:31.759 --> 00:11:35.720
Are you working to allow us to
do this or are you finding places where

154
00:11:35.759 --> 00:11:39.759
you can do this where we'll see
the performance gained without actually having to modify

155
00:11:39.799 --> 00:11:43.279
the way we write code or correct
So the idea with the optimizations I've been

156
00:11:43.279 --> 00:11:48.360
doing is to the Ruby interpreter or
the virtual machine changing adding instructions, changing

157
00:11:48.360 --> 00:11:52.440
how instructions are implemented. A lot
of changes are in the compiler or changing

158
00:11:52.440 --> 00:11:56.519
which instructions are you used, and
the idea is no, you won't need

159
00:11:56.559 --> 00:12:00.799
to modify any of your Ruby code. But Ruby code previously allocated a lot

160
00:12:00.840 --> 00:12:03.519
of objects, or at least some
objects, like for each method call,

161
00:12:03.559 --> 00:12:07.840
the allocating objects even if you didn't
have an object, like you're not creating

162
00:12:07.879 --> 00:12:11.399
a ray, but real be sort
of creating or internally. So my goal.

163
00:12:13.159 --> 00:12:16.559
The thing is you can't because of
the way Ruby works, like flat

164
00:12:16.639 --> 00:12:22.000
parameters, keywords, splat parameters,
there's no way to completely eliminate these implicit

165
00:12:22.039 --> 00:12:26.120
allocations. You can't do it.
It's just required by the language. But

166
00:12:26.240 --> 00:12:30.279
we can make it. My goal
is to make it so that any method

167
00:12:30.320 --> 00:12:35.399
call will not allocate more than one
array and more than one hash. That's

168
00:12:35.480 --> 00:12:39.399
rightly so because previously, I mean, you could call a method and depending

169
00:12:39.399 --> 00:12:43.480
on what you're doing, be like
five six objects allocated for no reason.

170
00:12:43.759 --> 00:12:46.960
I mean not no reason. There's
reasons it was doing it, but it

171
00:12:46.679 --> 00:12:50.559
wasn't optimized to remove them. So
that's a lot of what I've been working

172
00:12:50.600 --> 00:12:54.240
on is to remove them. Yeah, and it seems like when I talk

173
00:12:54.279 --> 00:12:58.440
to people who say use go or
something like that, that's one of the

174
00:12:58.440 --> 00:13:03.600
things that often tout is, well, you know, I rewrote my app

175
00:13:03.600 --> 00:13:05.960
and Go and I could you know, I reduced the number of servers I

176
00:13:07.000 --> 00:13:11.159
had by like two or something.
And so this this is a step toward

177
00:13:11.279 --> 00:13:16.159
that. Where as we you know, we make it do less garbage collection,

178
00:13:16.360 --> 00:13:20.799
we spend less time doing the allocations, and we spend less memory overall

179
00:13:20.600 --> 00:13:24.200
doing this stuff and causing the garbage
collection to have to happen more frequently,

180
00:13:26.720 --> 00:13:31.480
we may be able to consolidate our
hardware usage or at least make it more

181
00:13:31.480 --> 00:13:33.399
performant that way as well. Right, Yeah, I mean, certainly goal

182
00:13:33.519 --> 00:13:37.080
go is always going to be faster
compiled on be faster than rebe. But

183
00:13:37.120 --> 00:13:41.039
the really question is, you know, straight off, Ruby generally is going

184
00:13:41.080 --> 00:13:46.039
to be more productive than those languages. Yes, some people may not think

185
00:13:46.039 --> 00:13:48.120
that. Some people don't. Some
people I can really rely on static types.

186
00:13:50.360 --> 00:13:54.039
I've heard some people's feelings saying that. But yeah, Ruby has like

187
00:13:54.120 --> 00:13:56.720
static typing support, but I haven't
used it. I can tell you whether

188
00:13:56.759 --> 00:14:00.200
it's good or not. It's certainly
not gonna be as good to ask like

189
00:14:00.240 --> 00:14:05.039
a language that's built on stating types
like Go or you know, Java.

190
00:14:05.600 --> 00:14:07.480
But in general, people think of
Ruby is a very productive language, and

191
00:14:07.519 --> 00:14:11.360
I think I think it is,
but yeah, one of the trade offs

192
00:14:11.360 --> 00:14:13.840
you make is that performance is not
going to be as good. So again,

193
00:14:13.919 --> 00:14:18.960
it depends on what you're trying to
optimize for. You're trying to optimize

194
00:14:18.960 --> 00:14:22.559
for develop productivity, or you try
trying to optimize for run time performance.

195
00:14:22.879 --> 00:14:26.919
I think Ruby it's obviously run time
performance is no. We try to make

196
00:14:26.960 --> 00:14:28.759
it better. As we're working on
RUB, we trying to make it as

197
00:14:28.799 --> 00:14:31.559
fast as we can, but it's
it's never going to be as fast as

198
00:14:31.720 --> 00:14:37.639
like SEE or rust or go.
Even so again, if you have super

199
00:14:37.639 --> 00:14:43.799
big performance needs, probably not a
good idea to use RUB for those M

200
00:14:45.639 --> 00:14:50.159
Yeah makes sense. I just still
I really love the different optimizations that are

201
00:14:50.200 --> 00:14:52.440
coming in. You mentioned that you
haven't done a lot with the typing.

202
00:14:54.320 --> 00:14:58.759
We talked to Soro Matsumoto, who's
working on URBS, talk to a few

203
00:15:00.159 --> 00:15:03.960
people about related things, trying to
get the guy behind type proft. I

204
00:15:05.000 --> 00:15:11.480
can't remember his name on the summit
moment Amazon. Yeah, So anyway,

205
00:15:11.480 --> 00:15:15.559
we're working on a lot of that, and I've talked to people on a

206
00:15:15.559 --> 00:15:18.600
lot of these different points, like
how they work under the hood. We

207
00:15:18.679 --> 00:15:22.919
also had Samuel Williams come on and
talk about a sink and falcon some currency

208
00:15:22.960 --> 00:15:26.039
stuff, and so, I mean, there's all kinds of stuff that's so

209
00:15:26.080 --> 00:15:30.639
exciting just to see it. Yeah, that's the things you ask like people

210
00:15:30.639 --> 00:15:33.879
at the future of Ruby is.
And then there's Ruby is so large that

211
00:15:33.919 --> 00:15:37.200
people have YEA dramatically different things of
what they're thinking about, even because of

212
00:15:37.240 --> 00:15:41.679
how I mean different things that were
going on in Ruby, and we have

213
00:15:41.519 --> 00:15:46.960
people focusing just on the parser,
or just people focusing just on the expression

214
00:15:46.960 --> 00:15:50.559
engine, on people focusing just on
the virtual machine, or a lot of

215
00:15:50.559 --> 00:15:54.000
people a lot of people focusing just
on wy git. And then one of

216
00:15:54.039 --> 00:15:56.200
the big things I think is in
three four, probably in three four,

217
00:15:58.080 --> 00:16:00.440
even if it's not the default,
will be the new parts, which is

218
00:16:00.480 --> 00:16:04.679
Prism. I'm sure if you've talked
to Kevin Newton about that, but him

219
00:16:04.679 --> 00:16:08.840
and his team are working on that. So the goal being to basically have

220
00:16:08.960 --> 00:16:15.039
Prism is the default parser for all
the Ruby implementations be is the long term

221
00:16:15.039 --> 00:16:19.679
goal. It's not there yet.
The parser part is fine, but taking

222
00:16:19.720 --> 00:16:26.679
Prism and making bringing into Ruby as
the default parser requires in the grit rate

223
00:16:26.039 --> 00:16:32.600
you change the compiler you're using.
The Prism parser doesn't use the same format

224
00:16:32.679 --> 00:16:37.279
that the existing what's called pars dot
y parser uses, so they've been working

225
00:16:37.279 --> 00:16:42.480
extensively on getting the Prism compiler to
basically compile Ruby code the same way the

226
00:16:42.519 --> 00:16:48.519
existing parser does. And that's very
challenging because Ruby, i think, more

227
00:16:48.519 --> 00:16:52.759
than any other language, goes out
of its way to be flexible in terms

228
00:16:52.799 --> 00:16:56.200
of the parsing, which makes it
extreme, makes the parts are extremely complex,

229
00:16:56.759 --> 00:17:00.799
and which also results in the compiler
being very complex as well. Yeah,

230
00:17:02.120 --> 00:17:04.880
to deal with all the different you
know, things that can happen in

231
00:17:06.000 --> 00:17:10.000
parsing. A lot of this is
just because things are who would say,

232
00:17:10.400 --> 00:17:15.079
are not incredibly well factored internally,
Like often you're making the same change in

233
00:17:15.160 --> 00:17:19.000
multiple places. A lot of it
for performance reasons, so like you know,

234
00:17:19.039 --> 00:17:22.839
you try to it's not like when
you call a method, it like

235
00:17:22.920 --> 00:17:26.759
splits up the path. The method
takes into like a large number of different

236
00:17:26.799 --> 00:17:32.319
paths, each separately optimized for performance, which is good for performance, but

237
00:17:32.759 --> 00:17:37.000
for maintenance makes things significantly more challenged. Yeah, that makes sense. Yeah,

238
00:17:37.000 --> 00:17:41.160
I've been having some back and forth
with Kevin, so yeah, super

239
00:17:41.200 --> 00:17:48.480
excited to see where that leads us. As far as you know, we've

240
00:17:48.519 --> 00:17:52.599
been talking kind of about Ruby and
about some of the technical pieces of the

241
00:17:52.400 --> 00:17:56.160
you know, whether it's the parser, the VM or you know, some

242
00:17:56.200 --> 00:18:02.720
of these things with memory management and
performance. Where do you see things going

243
00:18:03.200 --> 00:18:04.559
kind of in the broader world of
Ruby. Right, So now we're talking

244
00:18:04.640 --> 00:18:07.920
about like rack, which I know
you've contributed to, or Rota, or

245
00:18:08.400 --> 00:18:11.799
you know, building apps, you
know, whether it's Rails or whether it's

246
00:18:11.799 --> 00:18:17.680
something else or who whatever. Yeah, in terms of the future Ruby,

247
00:18:17.839 --> 00:18:18.960
I think most people are still going
to be using Rails. I mean,

248
00:18:19.039 --> 00:18:23.079
Rails is so popular. I mean
I don't use Rails, but I mean

249
00:18:23.160 --> 00:18:27.880
so many other people do. I
don't expect that to change in the near

250
00:18:27.920 --> 00:18:32.480
future, if we're in the far
future even right, But Rails will also

251
00:18:32.519 --> 00:18:36.720
be like most people's reason to use
Ruby. It's okay, I mean it

252
00:18:36.759 --> 00:18:38.839
brings a lot of people in.
I started using Ruby because I was,

253
00:18:40.240 --> 00:18:44.240
you know, originally doing like Python
and PHP before I got into Ruby,

254
00:18:44.640 --> 00:18:48.359
and right that got me into Ruby
was Rails. So it's not like Rails

255
00:18:48.640 --> 00:18:52.079
brings people into the Ruby committee.
Tons of people. A lot of people

256
00:18:52.119 --> 00:18:55.240
that are in Ruby would not be
in Ruby if it wasn't for Rails.

257
00:18:55.319 --> 00:18:59.880
So rather think Ruby itself owes rails
quite a bit just for bringing people in

258
00:19:00.799 --> 00:19:03.640
and broadening the community. So I
think a lot of even if you don't

259
00:19:03.720 --> 00:19:07.920
use rails, you benefit from the
larger Ruby community that Rails brings in.

260
00:19:10.200 --> 00:19:11.759
See, I don't expect that to
change, uh. In terms of my

261
00:19:11.839 --> 00:19:18.680
libraries like Seql, road U,
roade off other things like that they get

262
00:19:18.720 --> 00:19:22.640
updated. I mean Sequel gets updated
and Rota gets updated every month. Every

263
00:19:22.640 --> 00:19:25.960
month. There's new features, new
things to try out. But there's nothing

264
00:19:26.000 --> 00:19:30.279
I wouldn't say there's like huge changes
on the rise, and like a lot

265
00:19:30.319 --> 00:19:33.799
of things are Rails adding or like
what sort of say things you would think

266
00:19:33.799 --> 00:19:36.759
about sort of being external to the
framework, and they're sort of bringing them

267
00:19:36.759 --> 00:19:40.000
in because what they want rails to
be, like you know, you've use

268
00:19:40.119 --> 00:19:44.640
rails, you're using you know,
used to be like just the object relational

269
00:19:44.680 --> 00:19:48.000
mapper and sort of framework part to
build things. And they've been expanding it.

270
00:19:48.039 --> 00:19:52.759
I mean yeah in many years.
I mean you were talking about they

271
00:19:52.880 --> 00:19:56.799
built in the you know, document
upload thing, active storage for bringing in

272
00:19:57.000 --> 00:20:03.200
like actually mailt across kind of emails
now they have like solid queue and a

273
00:20:03.240 --> 00:20:06.279
whole bunch of things they're adding that
are sort of outside the core framework,

274
00:20:06.319 --> 00:20:10.039
but they're building around it. So
again the idea is if you run rails,

275
00:20:10.319 --> 00:20:14.400
more people are running are sort of
the same thing. That's one of

276
00:20:14.400 --> 00:20:15.920
the things people like about Rails is
like, I've already worked on one Rails

277
00:20:15.920 --> 00:20:19.359
app. I had worked on you
know, everyone else's Rails app, which

278
00:20:19.359 --> 00:20:22.039
is not exactly true, but it
is. It is pretty true that,

279
00:20:22.200 --> 00:20:26.960
you know, rails apps tend to
be very similar. That's one of the

280
00:20:26.000 --> 00:20:30.039
reasons that I don't even try to
do that with RODA. Roda is basically

281
00:20:30.160 --> 00:20:33.359
like, here's a minimal framework,
here's a whole bunch of plug ins,

282
00:20:33.440 --> 00:20:37.960
sort of build exactly what you need, which is definitely percent not what Rails

283
00:20:38.039 --> 00:20:41.200
is. Rails is they called oma
cat, which is like, you know,

284
00:20:41.359 --> 00:20:48.000
this out is deal with Italy,
build exactly what you need, what's

285
00:20:48.039 --> 00:20:53.200
best for you, and that's there's
a double edged sword. Sometimes if you're

286
00:20:53.240 --> 00:20:57.319
comfortable with that, it's great,
it's exactly what you want. But certainly

287
00:20:57.319 --> 00:21:00.599
if you look at one road to
app and differ road to app, they're

288
00:21:00.599 --> 00:21:04.759
not necessarily going to be as similar. As to rails apps, again,

289
00:21:06.160 --> 00:21:08.440
with a larger development team, you're
hiring a bunch of other people that already

290
00:21:08.440 --> 00:21:12.519
know it. It's very helpful to
have Rails for that. If that's not

291
00:21:12.640 --> 00:21:17.200
the situation you're in and you're comfortable
building everything yourself, and then like RODA

292
00:21:17.480 --> 00:21:18.640
makes a lot more sense. It's
a lot simpler, a lot easier to

293
00:21:18.720 --> 00:21:23.839
understand. There's less i'd say churn
when upgrading things like that, so it's

294
00:21:23.880 --> 00:21:26.799
a trade off. And again for
a lot of people, the trade off

295
00:21:26.920 --> 00:21:30.240
the Rails makes as good, and
that's that's great. I'm not one of

296
00:21:30.240 --> 00:21:33.759
the people like I want to take
over the world and everyone should use my

297
00:21:33.759 --> 00:21:36.680
software. Roada is very good for
me. It's very good for what it

298
00:21:36.720 --> 00:21:37.839
does. A lot of people use
it now, but it's never going to

299
00:21:37.839 --> 00:21:42.160
be as popular as Rails. I'm
completely comfortable with that. Yeah, it's

300
00:21:42.200 --> 00:21:47.480
Equel and Active Record. I think
the sequel is technically a lot better but

301
00:21:47.640 --> 00:21:51.000
Rail, but Active Record has been
significantly improving in recent versions too. It's

302
00:21:51.039 --> 00:21:53.119
i'd say, caught up a lot
of the way from where it was,

303
00:21:53.640 --> 00:21:57.519
you know, ten fifteen years ago. It's I think still I still think

304
00:21:57.519 --> 00:22:00.720
the sequel is better. Technically,
there are problems that I think act the

305
00:22:00.799 --> 00:22:04.880
record has that sequel solves still,
but it's much closer now than it was

306
00:22:04.920 --> 00:22:11.720
ten or fifteen years ago. Right, So, so do you see any

307
00:22:11.759 --> 00:22:15.960
advance was coming in Ruby or changes
in the community that are going to affect

308
00:22:15.039 --> 00:22:18.680
the direction you head in or do
you think things like you said of Ruby

309
00:22:19.039 --> 00:22:22.200
are just going to kind of continue
the way they're going. Certainly language is

310
00:22:22.200 --> 00:22:26.319
going to continue. One of the
things I'm quite excited about myself is to

311
00:22:26.359 --> 00:22:30.200
see, like certainly when COVID hit
and the Roby community in terms of like

312
00:22:30.279 --> 00:22:34.599
conferences meetups almost immediately shut down Dor
to covid. It's not unique to RUBE.

313
00:22:34.720 --> 00:22:37.920
That's i'd say, across the board
from most places. Yeah, I

314
00:22:37.960 --> 00:22:42.279
am very excited to see, especially
this year, just tons like it was

315
00:22:42.319 --> 00:22:48.359
in the late twenty tens, tons
of reconferences coming back. You know,

316
00:22:48.400 --> 00:22:53.160
Like there's like twenty conferences already you
know this year that are scheduled and there's

317
00:22:53.160 --> 00:22:56.680
probably going to be more, which
is really exciting from a community basis.

318
00:22:56.680 --> 00:23:00.680
If you want to get involved or
meet people in the community, it's gonna

319
00:23:00.680 --> 00:23:03.039
be much easier now than it was
like two or three years ago. She's

320
00:23:03.279 --> 00:23:08.519
something I'm excited about as well.
Yeah, I had that conversation with Amanda

321
00:23:08.559 --> 00:23:15.400
Parino from the Rails Foundation. She's
the director of the Foundation, and it

322
00:23:15.799 --> 00:23:19.119
was interesting just kind of from that
community standpoint, right, just talking about

323
00:23:19.119 --> 00:23:22.200
some of the things that are coming
back, maybe some of the hiccups or

324
00:23:22.240 --> 00:23:26.400
struggles with maybe having as many of
the meetups and things that we used to

325
00:23:26.440 --> 00:23:29.640
have, but still we're seeing a
lot of that get revived and it's very

326
00:23:29.680 --> 00:23:34.319
exciting. Yeah, I'm definitely excited
about that. Yeah. Is there anything

327
00:23:34.319 --> 00:23:37.799
else that you're working on or things
you see out there in the community at

328
00:23:37.880 --> 00:23:42.359
large that you're excited about or uh
No, not really. I mean I

329
00:23:42.359 --> 00:23:45.960
haven't had as much time to work
on Ruby recently. I've had been much

330
00:23:47.079 --> 00:23:51.359
busier than I normally am and I
probably continued this year and maybe really not

331
00:23:51.359 --> 00:23:53.920
sure, so I probably don't be
as involved as I was. I mean

332
00:23:55.000 --> 00:23:59.319
I was also very busy last year. But right, hopefully any couple of

333
00:23:59.400 --> 00:24:03.240
years I'll be able to get back
more into, you know, contributing more

334
00:24:03.480 --> 00:24:07.160
more like I used to, you
know, from like twenty nineteen at like

335
00:24:07.200 --> 00:24:11.359
twenty twenty two. So I'm hoping
to do that, but it's probably I'm

336
00:24:11.400 --> 00:24:17.240
gonna say a year eighteen months away
before I can only get more involved.

337
00:24:17.240 --> 00:24:18.680
I still I still gonna be helping
out. You know, every one thought

338
00:24:18.680 --> 00:24:22.119
we would be contributing stuff, but
it won't be the frequency that I would

339
00:24:22.160 --> 00:24:29.279
prefer to be at. Cool.
Well, we still have a few minutes.

340
00:24:29.319 --> 00:24:30.200
Do you want to talk about your
book for a second. Let people

341
00:24:30.240 --> 00:24:36.279
know what it's about. Sure,
so Polish reprogramming. It's different than most

342
00:24:36.279 --> 00:24:38.119
of other review books. It assumes
you already know review fairly well, and

343
00:24:38.160 --> 00:24:45.640
it sort of talks about trade offs
to make when you're designing applications and libraries

344
00:24:45.799 --> 00:24:49.160
designed for intermedia or a revie programmer
sort of to reach the next level.

345
00:24:49.680 --> 00:24:55.319
It still sells fairly well. I
mean certainly sales have dropped off since it

346
00:24:55.359 --> 00:24:59.000
was released till I think two and
a half years ago. It still sells

347
00:24:59.039 --> 00:25:02.559
decently. I get every week your
books sold this much. So, uh,

348
00:25:02.759 --> 00:25:06.359
it's still doing well. I'm happy
about it. I'm not eager to

349
00:25:06.359 --> 00:25:10.640
write a follow up anytime soon,
because I think we talked about that doing

350
00:25:10.680 --> 00:25:12.200
the regrows thing. Writing a book
is this incredible about of work, and

351
00:25:12.640 --> 00:25:17.000
I don't think I want to get
involved in that, uh, not anytime

352
00:25:17.079 --> 00:25:18.599
soon at least, and I'm not
eager to get back and back in the

353
00:25:18.599 --> 00:25:23.000
saddle. Yeah, I'm I'm I'm
I'm happy, happy, it's doing well,

354
00:25:23.039 --> 00:25:26.480
and it's still seems to me I
still see places where it's not recommended

355
00:25:26.559 --> 00:25:32.440
for, you know, the audiences
intended form, which is great. Cool.

356
00:25:33.119 --> 00:25:34.319
All right, well, I'll go
ahead and wrap us up. Then

357
00:25:34.920 --> 00:25:41.200
thank you again for coming. Going
all right, well, until next time, folks,