WEBVTT

1
00:00:04.480 --> 00:00:08.119
Hey, everybody, Welcome to another
episode of the Ruby Roags podcast. I'm

2
00:00:08.160 --> 00:00:11.960
your host today, Valentino stul.
I'm joined by co host I Usual Hey,

3
00:00:12.640 --> 00:00:16.079
and we have a very special guest
today, Peter Owler. Peter,

4
00:00:16.679 --> 00:00:22.600
why don't you introduce yourself, maybe
tell us a little bit about how you're

5
00:00:22.640 --> 00:00:25.719
so great in the Ruby community and
all the lovely stuff you're working on.

6
00:00:26.559 --> 00:00:31.320
I don't know if I can claim
greatness, but I started with Ruby quite

7
00:00:31.359 --> 00:00:39.560
a while ago, early twenty twelve, somewhere maybe twenty eleven. I was

8
00:00:39.560 --> 00:00:46.880
a over in Japan, started working
for a company KBH, and we're starting

9
00:00:46.880 --> 00:00:55.119
to put together web wealfering and decided
the best way to where the best language

10
00:00:55.119 --> 00:01:00.240
would be Ruby. So we started
on that and I found out that well,

11
00:01:00.280 --> 00:01:03.000
first of all that the Jason parser
was really slow, so I wrote

12
00:01:03.079 --> 00:01:11.519
Jason parser was a bit faster.
And years later, after after leaving Japan,

13
00:01:12.280 --> 00:01:15.799
I decided that it would be a
good idea to make a more high

14
00:01:15.799 --> 00:01:23.799
performance web server and also stick in
to draft you ol, which had started

15
00:01:23.840 --> 00:01:29.400
to become popular at the time,
and the rooview offering I was pretty pitiful,

16
00:01:29.480 --> 00:01:33.640
actually, so I try to make
some to know is easier to use

17
00:01:34.480 --> 00:01:42.079
and higher performance. And that's I'll
go so real quick. Just when you

18
00:01:42.120 --> 00:01:49.200
say Jason parser, you mean the
ojjem right, yes, exactly. I

19
00:01:49.200 --> 00:01:53.319
think it's very popular and that's kind
of come the de facto, at least

20
00:01:53.319 --> 00:01:59.519
in my opinion, of which Jason
parsa to use for its speed and performance.

21
00:02:00.120 --> 00:02:06.400
So I think that's good to clarify. So I'm super interested in this

22
00:02:06.560 --> 00:02:12.479
Ago web server. It is a
web server, right, like it is

23
00:02:12.520 --> 00:02:16.000
a web service pretty awesome. So
you have a ton of benchmarks on here,

24
00:02:16.039 --> 00:02:21.360
which is kind of incredible. Do
you want to just kind of like

25
00:02:22.520 --> 00:02:28.439
walk us through the high level like
why use this over you know, even

26
00:02:28.520 --> 00:02:32.759
Sinatra or something like that, right? Well, I mean Sinatra has been

27
00:02:32.800 --> 00:02:38.599
around a long time and it works
fine, but its focus wasn't so much

28
00:02:38.599 --> 00:02:43.879
on performance as it was on maybe
ease of use or you know, getting

29
00:02:43.919 --> 00:02:49.199
things to work, because it was
it was an early system. It's all

30
00:02:49.199 --> 00:02:53.039
written in Ruby, which you know, it's great writing Ruby. I like

31
00:02:53.080 --> 00:02:57.960
write in Ruby. But if you're
going to go for performance, you need

32
00:02:58.000 --> 00:03:02.280
to make a cet extension too,
Yeah, to get all the all you

33
00:03:02.319 --> 00:03:07.960
can out of it. And that's
again that's part of the reason that i'll

34
00:03:07.960 --> 00:03:15.159
go came about so in terms of
Sinatra, Uh works great. If you

35
00:03:15.240 --> 00:03:20.199
want a bit higher performance, then
i'll go is probably the way. If

36
00:03:20.199 --> 00:03:25.400
you're going graph q WEL, I
would definitely suggest i'll go, just because

37
00:03:25.599 --> 00:03:31.800
the the current offering with Ruby for
for graph ql is much harder to work

38
00:03:31.840 --> 00:03:37.280
with with. With i'll go,
all you have to do is basically say,

39
00:03:37.280 --> 00:03:40.680
here's my class. As long as
it implements, uh, the appropriate

40
00:03:40.719 --> 00:03:46.520
method, then you're off and running. Honestly, I I really love this

41
00:03:46.639 --> 00:03:53.639
use case. If talking yeah graph
col I've been looking for like just drop

42
00:03:53.680 --> 00:03:55.360
in, Hey, I want to
use graph QL and Ruby, and uh

43
00:03:55.879 --> 00:04:00.520
there's like you know, you can
use it in a reils context with graph

44
00:04:00.599 --> 00:04:03.439
cool ruby JEM. Uh is that
what this is using under the hood or

45
00:04:03.719 --> 00:04:14.319
is it it's customer implementation that's awesome
all retinancy. Yeah, so this is

46
00:04:14.360 --> 00:04:17.079
super appealing to me. I'm gonna
have to give this a try. Uh

47
00:04:17.480 --> 00:04:25.639
what uh what sparked kind of like
do you are you like graph q L,

48
00:04:25.879 --> 00:04:30.040
like you know we should use this
for most things? Or what sparked

49
00:04:30.079 --> 00:04:36.759
the need to start here? In
my work? I started to use graph

50
00:04:36.839 --> 00:04:46.000
ql and uh again found most of
the implementations the APIs are very clunky order

51
00:04:46.079 --> 00:04:50.240
to use. So I wrote something
for I'll go, and I also wrote

52
00:04:50.279 --> 00:04:57.600
something for go both. We'll try
to make it as easy to use as

53
00:04:57.639 --> 00:05:03.240
possible, again not not requiring a
whole lot of wrappers and build up,

54
00:05:03.560 --> 00:05:10.360
but basically just pointed at the class
you're interested in exposing as a graph kol

55
00:05:10.399 --> 00:05:14.399
object, and you know, I
want to run its course. And that

56
00:05:14.519 --> 00:05:17.680
was kind of the approach. I
wanted something that I could use that was

57
00:05:18.920 --> 00:05:25.480
well, that was easier to use, and I go as a rock compliant

58
00:05:25.560 --> 00:05:29.560
right, so you can use it
with any any RACK app. Yes,

59
00:05:29.920 --> 00:05:36.079
exactly cool. It actually has some
other features as well, as you may

60
00:05:36.240 --> 00:05:42.000
it might be where a graph well
also does push. And we were trying

61
00:05:42.000 --> 00:05:49.079
to myself and another fellow, we're
trying to get well API, especially update

62
00:05:49.120 --> 00:05:57.240
the specification for Rack to support that, without much success. We went back

63
00:05:57.240 --> 00:06:00.279
and forth the number of times,
and there were enough people that were not

64
00:06:00.439 --> 00:06:05.199
interested in seeing that or didn't want
to have the API extended that it never

65
00:06:05.240 --> 00:06:11.519
made it. But it's available in
a GO. That's awesome. I mean

66
00:06:11.600 --> 00:06:16.439
I was looking at the some of
the documentation here on the graph cool stuff.

67
00:06:16.639 --> 00:06:21.279
And it seems to support subscriptions,
which is really interesting. Yes,

68
00:06:21.319 --> 00:06:27.399
that's what I was referring to.
Yeah, gotcha, So, like,

69
00:06:27.439 --> 00:06:30.680
how does I'm curious for those that
don't know, graphical subscriptions are way to

70
00:06:30.759 --> 00:06:36.279
kind of stream responses. Uh so, how does that kind of work under

71
00:06:36.279 --> 00:06:42.199
the hood? Uh? Use,
Well, you can use a number of

72
00:06:42.240 --> 00:06:47.040
implementations web sockets as well. My
preferred choice if you're using browser, if

73
00:06:47.079 --> 00:06:54.000
you're if you're trying to set up
an out of banned subscription, and I

74
00:06:54.040 --> 00:07:00.199
typically use something like gnats, which
is a messaging system. And so is

75
00:07:00.199 --> 00:07:03.399
the key feature of AGO? Is
it high performance or is it graph ql

76
00:07:03.639 --> 00:07:10.120
or is it both? Yes,
it's both, okay, high performance and

77
00:07:10.959 --> 00:07:15.120
easy to use graft quel cool.
So like if I was approaching it like

78
00:07:15.199 --> 00:07:19.920
an idiot and say say that,
I'm said idiot who builds rails apps,

79
00:07:19.959 --> 00:07:27.120
simple rails crad apps, and I
used Puma. What's the reason for me

80
00:07:27.199 --> 00:07:30.879
to drop Puma for Ago? Or
is that? Is that not the right

81
00:07:30.000 --> 00:07:33.160
use case for it? So say
that again? Maybe? So like,

82
00:07:33.240 --> 00:07:39.240
Okay, so I just built rails
apps, I build crad rails apps,

83
00:07:40.160 --> 00:07:43.519
and I used Puma as my web
server. So if you were explaining it

84
00:07:43.800 --> 00:07:49.240
to an idiot in this case me, what's the reason to drop Puma for

85
00:07:49.399 --> 00:07:55.560
Ago or is it not the right
use case for Ago? It depends on

86
00:07:55.800 --> 00:08:00.720
the the amount of well a man
of a question get is if you need

87
00:08:00.759 --> 00:08:05.240
something higher performance, then you might
go with a Goo. If you wanted

88
00:08:05.279 --> 00:08:11.759
to step into the graft uel world
again, I'll go and with Ago.

89
00:08:11.839 --> 00:08:16.439
That I wouldn't need like uh enginets
or Caddie reverse proxy in front of Puma.

90
00:08:16.480 --> 00:08:20.040
I'm guessing because that's the usual set
up with reels, isn't it.

91
00:08:20.079 --> 00:08:24.120
You have a reverse proxy because Puma
is not very performance, so you need

92
00:08:24.759 --> 00:08:28.439
like a web server in front of
it to serve static assets and stuff.

93
00:08:28.959 --> 00:08:33.679
But I'm guessing with I Goo,
that's not a problem. That's right,

94
00:08:33.039 --> 00:08:39.679
exactly true. One of the Ago
also does support having multiple workers in in

95
00:08:39.840 --> 00:08:46.600
separate h and I want going to
say separate threads and separate worked applications.

96
00:08:46.320 --> 00:08:50.919
The well, the advantage of that, of course is is you get around

97
00:08:50.000 --> 00:08:56.960
the GVO lot that you have with
Ruby because you can have a number of

98
00:08:56.159 --> 00:09:01.039
workers all turning away at the same
time. The problem is that if you

99
00:09:01.120 --> 00:09:07.120
have shared data and access in that
shared data. Typically a database has overhead

100
00:09:07.120 --> 00:09:11.639
in itself as opposed to having everything
in the same process, like within a

101
00:09:11.679 --> 00:09:16.679
hash map or something like that.
So it's a trade off, and you

102
00:09:16.720 --> 00:09:22.559
have to look at your application to
decide if you if you are interested in

103
00:09:22.559 --> 00:09:28.159
in uh in just starting out with
graft cool and want a nice example I

104
00:09:28.200 --> 00:09:35.279
do. I did write a paper
for what was it, uh app signal?

105
00:09:37.480 --> 00:09:43.600
Okay, it's called well, it's
a song application. If you're on

106
00:09:43.639 --> 00:09:46.799
the read me page or I'll go, you'll see a reference there under the

107
00:09:46.879 --> 00:09:52.559
news and it's the second news item. But that walks you through it.

108
00:09:54.159 --> 00:09:56.080
Yeah. Yeah, I've never seen
graft yell before. I don't know what

109
00:09:56.120 --> 00:10:01.600
I'm doing here. We go here
to do it? M hm yep,

110
00:10:01.679 --> 00:10:05.480
I see that there. I'll give
that a read a bit later on.

111
00:10:07.600 --> 00:10:11.519
So what is it that makes I
go so high performance? Is it just

112
00:10:11.559 --> 00:10:16.600
the fact that it's written in C
or is there something other, something else,

113
00:10:16.639 --> 00:10:22.879
a bit clever going on. Of
course, there's something more clever has

114
00:10:22.960 --> 00:10:31.039
to be languages. Languages aren't what
give you the performance by themselves. What

115
00:10:31.080 --> 00:10:35.200
they do is they give you the
means to make something faster. So there's

116
00:10:35.320 --> 00:10:41.240
less overhead in c than there is
in Ruby. That doesn't mean just because

117
00:10:41.240 --> 00:10:43.240
you write it and see that it's
going to be faster. I've seen plenty

118
00:10:43.240 --> 00:10:50.440
of code that's written in CEE that
is the basmally slow. One of the

119
00:10:50.600 --> 00:10:56.279
one of the things that al Go
does is it uses multiple threads. Now

120
00:10:56.320 --> 00:11:03.039
that's a problem with Ruby because multiple
threads means you've got to keep handing over

121
00:11:03.120 --> 00:11:07.399
the GVL, which there's overhead in
that. With all Go, what happens

122
00:11:07.480 --> 00:11:11.519
is the request comes in, it
gets put on a queue, that que

123
00:11:11.559 --> 00:11:18.279
gets picked up by nd number of
worker threads. They process the request,

124
00:11:18.840 --> 00:11:22.559
and it's only when it gets to
the well, the very end where it

125
00:11:22.639 --> 00:11:28.200
hits the Ruby side again, where
it gets the GVL, does the work,

126
00:11:28.960 --> 00:11:33.519
gets the response, gives up the
lock, and then sends a response

127
00:11:33.559 --> 00:11:37.399
back to their request. So probably
ninety percent of the work is done outside

128
00:11:37.440 --> 00:11:43.399
of Ruby. This reminds me a
lot of Shopify's pitchfork. Are you familiar

129
00:11:43.440 --> 00:11:46.919
with that? I'm done, No, I know what shopify is, but

130
00:11:48.559 --> 00:11:54.799
pitchboard they've been trying to I think
they've actually switched to using this, maybe

131
00:11:54.799 --> 00:12:03.720
not for their main monolith. But
it's a bit it's like a forked architecture

132
00:12:03.879 --> 00:12:11.639
hd t B server. It sounds
a little bit similar. Yeah, that

133
00:12:11.720 --> 00:12:16.279
happens at a different level with I'll
go the It has workers and those are

134
00:12:16.279 --> 00:12:22.159
basically forks of the whole process.
Within each one of those forks, there's

135
00:12:22.159 --> 00:12:28.399
still multiple threads that are processing the
HGP requests before it basically gets to the

136
00:12:28.480 --> 00:12:33.879
Ruby part and says that Ruby park, do your thing, get the response,

137
00:12:33.919 --> 00:12:37.840
and then again it leaves the Ruby
part alone and jumps back into multiple

138
00:12:37.879 --> 00:12:43.000
threads. Gotcha, and what's using? What are you using for the queuing

139
00:12:43.039 --> 00:12:52.440
system? Of course, of course
performance what performance is of utmost importance.

140
00:12:52.879 --> 00:12:58.759
You always write your own pretty much, so, I mean, I would

141
00:12:58.759 --> 00:13:01.000
love to dive into some of these
benchmarks. So you have a ton of

142
00:13:01.039 --> 00:13:05.799
benchmarks here in your repo. You
give one for a reels context as well.

143
00:13:07.639 --> 00:13:11.320
You know, how does it stack
up? Let's say, you know

144
00:13:11.519 --> 00:13:15.360
at I use this point, you
know, how does it stack up for

145
00:13:15.440 --> 00:13:20.799
a reels app running Puma? Like, what are how are the benchmarks?

146
00:13:22.559 --> 00:13:24.240
You know, it's been quite a
few years since I did the benchmarks.

147
00:13:24.279 --> 00:13:30.399
I don't remember what real what I
was using with rails at the time,

148
00:13:30.440 --> 00:13:39.600
whether it was Puma or something else. I didn't see big differences though the

149
00:13:39.159 --> 00:13:43.919
benchmarks were done with a single I
guess they're done in a couple of different

150
00:13:43.919 --> 00:13:46.919
ways, but in general not with
most workers, because with workers and you

151
00:13:48.000 --> 00:13:54.399
have to worry about the overhead of
the shared data star, which is typically

152
00:13:54.480 --> 00:14:03.200
quite a bit higher than what you
get from the web servers themselves. Gotcha,

153
00:14:03.279 --> 00:14:05.960
Yeah, I mean, I'm just
I keep circling back to the one

154
00:14:05.000 --> 00:14:11.039
hundred thousand requests per second and then
that kind of like you mentioned, you

155
00:14:11.039 --> 00:14:18.000
know, hitting the limitations of Ruby's
benchmark because it goes so fast. Can

156
00:14:18.039 --> 00:14:24.639
you elaborate kind of on on that, right, So your test tool has

157
00:14:24.679 --> 00:14:33.639
to be faster than what you're testing. So the original or what I was

158
00:14:33.679 --> 00:14:37.159
originally using for the Ruby benchmarks wasn't
able to keep up with the rates.

159
00:14:37.240 --> 00:14:41.879
So I had a I knew I
could go or I knew I could process

160
00:14:41.840 --> 00:14:48.039
more data than what was what the
benchmarks were showing. So I tried on

161
00:14:48.039 --> 00:14:56.720
my own and was able to get
a significant boosting and throughput or measured throughput.

162
00:14:56.759 --> 00:15:00.559
How do you know that? I'm
curious, like, where do you

163
00:15:00.559 --> 00:15:05.360
get to your point where you're like, like, I know you start Yeah,

164
00:15:05.480 --> 00:15:09.200
if you start up, well,
a webster is kind of unique because

165
00:15:09.200 --> 00:15:15.080
it can have requests coming in from
multiple sources. So if I started up

166
00:15:15.279 --> 00:15:20.120
two, three, four benchmarking tools
and were able to hammer on, I'll

167
00:15:20.120 --> 00:15:26.159
go and see that all three of
those benchmarking tools were pegged out, and

168
00:15:26.320 --> 00:15:31.240
I knew it to handle more than
than each one of those individuals. And

169
00:15:31.320 --> 00:15:43.399
what what protocols does this currently support? HGP? Oh no, it's just

170
00:15:43.720 --> 00:15:50.639
h GPH and HPS. It has
not been upgraded to use HP two yet,

171
00:15:50.679 --> 00:15:58.000
so it doesn't handle some of the
more well, some of the newer

172
00:15:58.039 --> 00:16:03.919
features. And what about web sockets? I'm guessing if you have graph cuel

173
00:16:04.120 --> 00:16:07.000
screaming as you said, then it's
about web sockets as well. Right,

174
00:16:07.639 --> 00:16:15.080
it does support web sockets yess so
school, So what are I'm curious?

175
00:16:15.120 --> 00:16:22.639
Like the real live you know,
how's it? How's it handling in production?

176
00:16:22.879 --> 00:16:25.720
Right? Like? Are you running
this in in production? Are you

177
00:16:25.799 --> 00:16:30.120
using it for like massive scale yet? You know? How is it faring?

178
00:16:30.039 --> 00:16:33.879
Yeah? I you know, I
have to just rely on the users

179
00:16:33.879 --> 00:16:40.240
to tell me that. And as
you may be, whereas open source projects

180
00:16:40.240 --> 00:16:45.080
typically don't get a lot of feedback
except for issues. So you get complaints,

181
00:16:45.120 --> 00:16:48.600
but you don't get any of the
any of the things that say,

182
00:16:48.639 --> 00:16:52.440
hey, it's doing great, Yeah, I like it a lot, or

183
00:16:52.440 --> 00:16:57.120
something like that. It's more about
issues. Often they start out with I

184
00:16:57.159 --> 00:17:06.079
really like it, but yeah,
I mean, honestly, this is like

185
00:17:06.119 --> 00:17:11.920
a I love like Again, it's
circling back to graph cuel like I feel

186
00:17:11.920 --> 00:17:18.640
like as like, uh you know, it's I'm torn because on one hand,

187
00:17:19.119 --> 00:17:22.880
most Ruby apps are are going to
be using rails in some capacity for

188
00:17:22.960 --> 00:17:30.839
their data connection, right uh,
and so it would be nice to just

189
00:17:30.880 --> 00:17:34.519
like quickly get a graphic el sever
up and running in a reels context.

190
00:17:37.599 --> 00:17:42.400
Is it fairly straightforward to like connect
all those pieces together and mount this uh

191
00:17:42.640 --> 00:17:48.799
like on its own uh like on
its own subprocess from rails or or FORDD

192
00:17:48.799 --> 00:17:56.119
process? What what is like kind
of like that path look like success?

193
00:17:56.839 --> 00:18:02.960
I haven't. I haven't done a
lot with rails myself, okay, as

194
00:18:03.000 --> 00:18:06.400
you might. As you know,
it's not a high performance system, so

195
00:18:06.839 --> 00:18:11.319
I tend to steer away from it. I'm curious then, if you if

196
00:18:11.319 --> 00:18:18.519
you're not using rails, what is
your preference for like database in combination with

197
00:18:18.640 --> 00:18:33.319
the graph kill side. I have
a feeling that will be the bottleneck right

198
00:18:40.119 --> 00:18:44.680
most of quite honestly, I'm doing
most of my latest work and Go,

199
00:18:45.039 --> 00:18:52.920
but the databases I'm typically using are
either Mango or redist. Okay, do

200
00:18:52.960 --> 00:18:57.880
you find that either of those would
be like probably most performance alongside of I'll

201
00:18:57.960 --> 00:19:06.039
go. It depends what you're trying
to build or what you're trying to store.

202
00:19:07.039 --> 00:19:12.319
Uh. Reddis is probably high performance
or higher performance, but it's a

203
00:19:12.359 --> 00:19:17.000
little bit more restricted than what you
can store or how you store it in

204
00:19:17.039 --> 00:19:21.359
there. Mango gives you a lot
more flexibility in terms of querity capabilities.

205
00:19:21.440 --> 00:19:26.279
And yeah, I'll admit it's been
a long time since I've used Mango.

206
00:19:26.599 --> 00:19:30.920
Uh, I'm curious, you know, since since you have experienced with that,

207
00:19:32.079 --> 00:19:36.200
Like, how how is the pace
kept up for the for Mango?

208
00:19:36.319 --> 00:19:41.200
Is it's still like fairly performant.
Oh? Yeah, definitely, it's only

209
00:19:41.200 --> 00:19:45.359
getting better. I forget why people
decided to switch off of it, to

210
00:19:45.400 --> 00:19:49.519
be honest, yeah, I don't
know why they would. We're still using

211
00:19:49.559 --> 00:19:56.759
it quite heavily and in both in
Go and in Ruby. But for Ruby

212
00:19:56.799 --> 00:20:00.559
it's kind of nice because you store
everything in Jason's So you take your Ruby

213
00:20:00.599 --> 00:20:06.759
object you encoded and just Jason and
you store it, fetch it back.

214
00:20:07.000 --> 00:20:11.559
Yeah, I mean, I remember
you ready to go. I remember my

215
00:20:11.680 --> 00:20:18.200
first Reels comp It was wildly popular, definitely amongst groupon as an example,

216
00:20:18.319 --> 00:20:22.880
which you know as much smaller now
and living social used to be a thing.

217
00:20:23.279 --> 00:20:26.759
I don't know if they're still around, but right I don't know why

218
00:20:26.880 --> 00:20:33.400
Mango kind of dropped off the Reels
and Ruby ecosystems. It's definitely not as

219
00:20:33.440 --> 00:20:37.240
prominent, but I always liked it
because you could just like dump data at

220
00:20:37.279 --> 00:20:45.079
it and it could handle it right
exactly. Yeah. It reminds me.

221
00:20:45.559 --> 00:20:48.599
I have a friend that's uh he
loves couch TB for the same reason.

222
00:20:48.640 --> 00:20:52.599
He's just like, you know,
relax, just get just go into the

223
00:20:52.640 --> 00:21:03.839
couch. That's funny. Uh So
that's interesting. So I'm curious, like,

224
00:21:03.119 --> 00:21:10.359
then, do you find it kind
of like a easier to connect graph

225
00:21:10.440 --> 00:21:15.599
col like typing system because you're using
Mango in those cases because it's so flexible,

226
00:21:15.000 --> 00:21:21.400
And then I imagine the data structures
are similar the uh well for graph

227
00:21:21.480 --> 00:21:26.119
col. The way I'll go works
is that data structures are just Ruby objects.

228
00:21:26.200 --> 00:21:30.839
So yeah, it's easy. It's
a Ruby object is easily encoded in

229
00:21:32.000 --> 00:21:37.519
Jayson, which is easily stored in
Mango and vice versa. That's really easy

230
00:21:37.599 --> 00:21:41.720
to say. Yes, it makes
it easy to say, hey, get

231
00:21:41.759 --> 00:21:45.359
me all my all my songs,
and you just do a query on the

232
00:21:45.440 --> 00:21:51.440
song database in Mango and there they
are. You pull them back out and

233
00:21:51.440 --> 00:21:56.440
they're already decoded and your work is
done. Oh that's really cool. I'm

234
00:21:56.480 --> 00:22:03.799
looking at your example now with the
artists and everything. Uh oh that's really

235
00:22:03.839 --> 00:22:11.960
cool. Yeah. Oh man,
I'm happy to be with this more so,

236
00:22:11.000 --> 00:22:18.160
I see you have locks in in
your mutations, all right it I

237
00:22:18.160 --> 00:22:23.359
I imagine there's a lot of like
internals happening in i goo that requires locking

238
00:22:23.400 --> 00:22:30.119
mechanisms. Actually, those locks are
are simply because you're well, because you're

239
00:22:30.160 --> 00:22:37.000
getting h fee requests. It allows
you to have multiple requests in process at

240
00:22:37.000 --> 00:22:41.519
the same time. Oh I see
now, so while i'll go can handle

241
00:22:41.519 --> 00:22:45.839
that nicely, the Ruby side of
things can't. So it may it may

242
00:22:45.880 --> 00:22:52.319
fire off multiple requests for the same
object. So unless you put a lock

243
00:22:52.400 --> 00:23:00.319
on the resource, then now you're
liable to get collisions. Well, this

244
00:23:00.400 --> 00:23:06.000
is really interesting because one of my
biggest complaints of like rails and like a

245
00:23:06.039 --> 00:23:11.880
background queuing processing system is like you
have to like load your entire application just

246
00:23:11.920 --> 00:23:17.880
to run a worker, which seems
like so bizarre to me. Which I

247
00:23:17.920 --> 00:23:22.759
know there are like some optimizations that
are made right on the on the constant

248
00:23:22.759 --> 00:23:27.480
loading side to help ease the pain
of that, which has gotten better,

249
00:23:27.559 --> 00:23:33.799
but it's still like not ideal.
Does does AGO kind of like help with

250
00:23:33.839 --> 00:23:40.039
that? Like have you have you
had a good experience like with like background

251
00:23:40.079 --> 00:23:45.279
workers, and I go, like
as a as an ecosystem, couple with

252
00:23:45.319 --> 00:23:51.319
the database. It works great.
You can get very high throughput and your

253
00:23:51.519 --> 00:23:56.240
bottleneck becomes a database, which is
kind of what you want, you know,

254
00:23:56.279 --> 00:24:03.799
you don't want the bottleneck to be
your application the you know. One

255
00:24:03.839 --> 00:24:07.759
of the things that I I did
notice early on was that the rails is

256
00:24:07.799 --> 00:24:12.440
great for putting together prototypes and you
know, for setting up you know,

257
00:24:12.480 --> 00:24:18.039
I want these windows to display my
data. Fantastic, But if you're looking

258
00:24:18.079 --> 00:24:22.440
for high performance, you know,
down the road, it becomes more and

259
00:24:22.480 --> 00:24:29.480
more difficult to get that performance with
with the rail, with the rails layers

260
00:24:29.480 --> 00:24:34.200
on top of it. So if
you can break your application up to have

261
00:24:34.400 --> 00:24:40.680
a high performance back end and with
you know, something that does just the

262
00:24:40.759 --> 00:24:45.160
view making use of RAILS. That
seems to be a good way to make

263
00:24:45.200 --> 00:24:55.279
it work. So when when you're
writing web applications with I go, do

264
00:24:55.319 --> 00:25:00.119
you use any framework or do you
just write like rock good? Uh,

265
00:25:00.400 --> 00:25:11.519
directly for the server, I don't
even use rack. You're going down a

266
00:25:11.640 --> 00:25:17.640
level even fatter than that then,
exactly. Yeah. The only thing I

267
00:25:17.680 --> 00:25:21.519
struggle with is, yeah, I'm
not very good with making pretty UIs and

268
00:25:21.599 --> 00:25:25.839
dealing with CSS and that kind of
thing. So yeah, it'd be nice

269
00:25:25.839 --> 00:25:29.319
to have somebody hold my hand on
that. It's kind of what rails does.

270
00:25:30.440 --> 00:25:37.400
But yeah, I'm curious, I'm
curious what you're like what your bottlenecks

271
00:25:37.440 --> 00:25:45.839
were like in Ruby itself, right, Like what kind of like when you're

272
00:25:45.480 --> 00:25:51.200
trying to test or like hit the
limits of the performance, like aside from

273
00:25:51.200 --> 00:25:55.799
the GVL, like what like kind
of bottlenecks where you're hitting just like in

274
00:25:55.839 --> 00:26:02.920
the Ruby ecosystem to push things further
the Uh So, it's a web server

275
00:26:03.240 --> 00:26:07.079
and the first thing it does after
it gets well after processes or requests and

276
00:26:07.119 --> 00:26:11.240
gets on too, and it calls
into Ruby. After that, you know,

277
00:26:11.279 --> 00:26:18.599
I'm kind of hands off. It's
whatever the you know, whatever the

278
00:26:18.599 --> 00:26:22.519
application developer has written that's going to
be have the impact on the performance.

279
00:26:22.559 --> 00:26:29.160
So really I just care about getting
stuff into and getting the results back.

280
00:26:30.160 --> 00:26:36.839
So if you've got a a large
Ruby result and you want to convert that

281
00:26:36.960 --> 00:26:44.200
to Jason, that'll take some time. Even with Okay, it's still more

282
00:26:44.240 --> 00:26:48.920
overhead than just saying here's a bunch
of texts. Right, So are you

283
00:26:48.960 --> 00:26:53.759
not doing any like connection pooling or
anything like that to like keep the connection

284
00:26:53.880 --> 00:26:57.759
open with you know, for multiple
requests kind of thing. Oh? Yeah,

285
00:26:57.960 --> 00:27:03.640
it does. It does keep the
connection open, Okay, and you

286
00:27:03.640 --> 00:27:07.680
can set the time out so that
you know after I mean, it'll it'll

287
00:27:07.759 --> 00:27:14.160
drop it. There's no activity.
Do you have any examples of like real

288
00:27:14.200 --> 00:27:21.599
world usages where where y'all using I
go and it's solved problems that couldn't be

289
00:27:21.640 --> 00:27:26.599
solved in another way. Yeah,
you're asking one person. I wrote the

290
00:27:26.680 --> 00:27:37.640
tools. I'm curious where like you
want to take take this too? Right?

291
00:27:37.759 --> 00:27:41.519
Like, uh, I can imagine
a whole bunch of use cases for

292
00:27:41.599 --> 00:27:48.039
it myself, But do you have
any like direction that you plan to continue

293
00:27:48.200 --> 00:27:53.799
pushing it to or I don't see
pushing it in any particular direction right now.

294
00:27:53.920 --> 00:27:59.079
It's it's kind of stable the way
it is. I guess the next

295
00:27:59.079 --> 00:28:03.119
step would be you know, web
two, but I haven't heard anybody really

296
00:28:03.119 --> 00:28:06.839
complaining a lot about that. Yeah, I mean, all I can think

297
00:28:06.880 --> 00:28:11.359
is people trying to hook this up
to action cable or or I guess,

298
00:28:11.599 --> 00:28:17.160
I guess, uh, probably any
cable at this point. Yeah. I

299
00:28:17.160 --> 00:28:21.920
think the biggest uh, I think
the biggest advantage of having ah GDP two

300
00:28:21.960 --> 00:28:26.680
support would be just multiplexing, because
you can if you're requesting assets, then

301
00:28:26.680 --> 00:28:32.440
you can send multiple assets down the
same TCP connection, whereas with ah GDP

302
00:28:32.599 --> 00:28:37.240
one point one they're all individual requests. I think for like web application developers

303
00:28:37.279 --> 00:28:42.400
like myself, that's been the biggest
attraction to h GDP two. It is

304
00:28:42.480 --> 00:28:48.799
just multiplexing, right And of course
with ago it's connections are pretty cheap.

305
00:28:48.799 --> 00:28:53.960
You could actually open up multiple connections
to a GOO and it'll process the requests

306
00:28:55.200 --> 00:29:03.720
in parallel. And I have seen
some people that is that processed fairly straightforward,

307
00:29:03.960 --> 00:29:07.000
just like opening up new connections to
it. Yeah, just open up

308
00:29:07.000 --> 00:29:15.000
a connection connection, Yeah, yeah, the bottleneck with the bottle neck that

309
00:29:15.119 --> 00:29:19.240
multiplexing salts and more on the client
side because a bras will learning I think

310
00:29:19.359 --> 00:29:26.559
open uh like six to eight connections
at a time, So if you have

311
00:29:26.079 --> 00:29:30.200
a vast number of assets that need
to be downloaded, that's going to be

312
00:29:30.240 --> 00:29:33.839
a client side bottleneck, which is
what multiplexing solts, because it'll just do

313
00:29:33.880 --> 00:29:45.160
it over a single TCP connection,
right right, Yeah, I think that

314
00:29:45.240 --> 00:29:49.839
most machines would have a hard time
keeping up with a whole lot more than

315
00:29:51.240 --> 00:29:57.960
six or eight connections, So yeah, yeah, exactly. But yeah,

316
00:29:57.960 --> 00:30:03.319
that's why I don't know the specifics
of how the magic that HGTP two does,

317
00:30:03.440 --> 00:30:08.960
but because it does it over a
single connection, it can get all

318
00:30:10.039 --> 00:30:17.240
those assets down pretty fast. So
that's kind of led to the usage of

319
00:30:17.279 --> 00:30:21.880
things like important maps and things like
that. Way you don't bundle your JavaScript,

320
00:30:21.960 --> 00:30:26.799
you have them as like twenty thirty
individual files, because suddenly getting multiple

321
00:30:26.839 --> 00:30:32.079
files down from the survey isn't that
expensive anymore. Right, there's still a

322
00:30:33.359 --> 00:30:37.559
still overhead. I think we're HDP
two helps on that is, if you've

323
00:30:37.559 --> 00:30:44.200
got well, if you don't have
let's say you're downloading arch assets you're pulling

324
00:30:44.200 --> 00:30:48.279
them from storage, there's going to
be delay as you're pulling each segment of

325
00:30:48.319 --> 00:30:53.000
those, so that lets you and
relieve it on the same connection. If

326
00:30:53.039 --> 00:30:59.680
the server can provide the data fast
enough so there's no delays, then it

327
00:30:59.759 --> 00:31:06.759
really doesn't provide any advantage over having
multiple connections. I mean your pipe is

328
00:31:06.799 --> 00:31:11.640
only so big. Yeah, yeah, that's true exactly. I haven't played

329
00:31:11.880 --> 00:31:18.880
a massive around haven't played around a
massive amount with the stuff myself, So

330
00:31:18.920 --> 00:31:23.200
I'm just talking from blog posts that
I've read and performance benefits of a c

331
00:31:23.359 --> 00:31:29.119
DP DOO. I'm far from an
expert right well, and it's also it

332
00:31:29.720 --> 00:31:33.480
depends on on what you're on.
What the application is doing with the data.

333
00:31:34.079 --> 00:31:40.799
Yeah, exactly, it's handling all
synchronously, then it really doesn't help

334
00:31:40.839 --> 00:31:44.759
it. If it can handle it
asynchronously, then I could definitely see an

335
00:31:44.759 --> 00:31:48.680
advantage there. Oh, so you
have an example on service events. Mm

336
00:31:48.759 --> 00:31:53.599
hmm. That's pretty cool. Interesting. So I'm curious. We talked a

337
00:31:53.599 --> 00:32:00.759
little bit before the show about your
heavy GO use. Uh so I'm curious

338
00:32:00.119 --> 00:32:05.759
just from your perspective, they're uh
kind of you know, where where do

339
00:32:05.799 --> 00:32:10.000
you see like GO as providing more
benefit over Ruby and in some of these

340
00:32:10.039 --> 00:32:17.039
performances, uh you know, metrics
like why use that a Go over like

341
00:32:17.440 --> 00:32:23.359
a Go web server as an example. Actually, the for the the Go

342
00:32:23.599 --> 00:32:30.119
version, I actually wrote it with
as for the company, and they allowed

343
00:32:30.119 --> 00:32:36.839
me to open source it. So
it's called giggle h and g g q

344
00:32:37.119 --> 00:32:47.319
L. We just frienctic giggle.
But on the other the other side of

345
00:32:47.319 --> 00:32:52.680
that is o j uh. It
is o J G o J for for

346
00:32:52.839 --> 00:32:58.200
Go, and it includes Jason Path
and and quite a bit of others.

347
00:32:59.440 --> 00:33:04.240
I guess the reason I've been drifting
more toward Go other than of course amusing

348
00:33:04.359 --> 00:33:07.720
for the company I work with,
is it it is higher performance, and

349
00:33:08.319 --> 00:33:15.440
honestly it's easier to work with a
harder team with it. It's a strong,

350
00:33:15.559 --> 00:33:22.480
more strongly typed which helps it.
Also, because of the way it's

351
00:33:22.480 --> 00:33:28.240
set up, it's easier to set
up packages and have different teams or different

352
00:33:28.279 --> 00:33:32.640
individuals working on different part portions of
the code and then bring it all together.

353
00:33:34.880 --> 00:33:39.480
Ah So I see, yeah,
I always I did like that about

354
00:33:39.559 --> 00:33:46.440
I only did a small amount of
Go development, but definitely the typing was

355
00:33:46.799 --> 00:33:52.279
very helpful for uh you know,
for people getting up to speed for things

356
00:33:52.359 --> 00:34:02.720
quickly and they just and for the
types and sometimes but I'm curious, like,

357
00:34:05.319 --> 00:34:09.239
you know, what about what about
Ruby is limiting for like larger teams,

358
00:34:09.280 --> 00:34:13.679
like working on the same thing.
Is it just like the packaging ecosystem

359
00:34:13.800 --> 00:34:19.199
of Go that's more beneficial in that
respect? Yeah, I think Go has

360
00:34:19.199 --> 00:34:23.719
a little more it's a little more
structured development environment. So there's a lot

361
00:34:23.760 --> 00:34:31.760
of tools that help you measure coverage, measure do benchmarks, kind of enforces

362
00:34:31.800 --> 00:34:42.280
testing. Ruby is well and rightly
so it's it's a little more free form.

363
00:34:43.719 --> 00:34:49.400
It's great for small projects. I
like it. If I'm writing something

364
00:34:49.400 --> 00:34:54.840
for myself, well, I work
in the US in Canada, so I

365
00:34:54.880 --> 00:34:59.440
had a horrible time finding a bookkeeping
system that would work. So I wrote

366
00:34:59.440 --> 00:35:04.199
my own, and of course I
wrote in Ruby. There's no way I

367
00:35:04.239 --> 00:35:08.039
was gonna attempt that to go.
Uhh. Ruby is just easier, more

368
00:35:08.079 --> 00:35:15.440
fun to work with. It just
doesn't scale us nicely with with larger teams.

369
00:35:15.840 --> 00:35:22.599
That's fair. Uh yeah, So
I'm curious other details, like maybe

370
00:35:22.719 --> 00:35:29.679
uh like about o J specifically,
is there something more performant about OJ and

371
00:35:29.719 --> 00:35:37.039
GO over Ruby? Uh? Well, yeah, there's there's less overhead and

372
00:35:37.039 --> 00:35:42.079
creating the objects. I think that's
probably the biggest difference. I actually use

373
00:35:42.159 --> 00:35:47.239
a similar approach, a single past
parser ah to do the parson, which

374
00:35:47.239 --> 00:35:52.760
helps a lot, a lot of
tweaking there trying to figure out It helps

375
00:35:52.800 --> 00:35:58.000
you learn the language a lot when
you when you test out different approaches to

376
00:35:58.079 --> 00:36:00.960
solving the problem. Now, the
overhead of a function call, the overhead

377
00:36:00.960 --> 00:36:07.239
of a number of arguments, the
number of return arguments, passing function pointers,

378
00:36:07.280 --> 00:36:12.079
all those things come into play.
I gotcha. So would you say,

379
00:36:12.119 --> 00:36:19.400
like Ruby objects are bloated in comparison, No, it's a uh,

380
00:36:19.519 --> 00:36:23.800
they're different more the mechanisms. I'm
just curious. I don't know that.

381
00:36:25.679 --> 00:36:30.639
Yeah. So, so think of
you can write C code and you can

382
00:36:30.679 --> 00:36:36.239
have structs, and you know,
you can attach functions to them, and

383
00:36:36.599 --> 00:36:40.239
they kind of look like objects.
You've got to go and you don't have

384
00:36:40.280 --> 00:36:44.000
to do as much work under the
covers to make your objects. You know,

385
00:36:44.039 --> 00:36:47.719
the same thing, though you've got
attributes. Uh, the inherence mechanism,

386
00:36:47.960 --> 00:36:53.880
inheritance mechanisms. A little yeah,
less, I'd like it as much

387
00:36:53.920 --> 00:37:01.079
as as I do Ruby. But
Ruby is much more more flexible and much

388
00:37:01.079 --> 00:37:08.519
more powerful in terms of inheritance and
the way you can embed or include code

389
00:37:09.440 --> 00:37:15.039
when you're working. Honestly, it
reminds me a lot of Lisp, which

390
00:37:15.079 --> 00:37:24.159
is was my first serious language,
you know, past basic that is in

391
00:37:24.320 --> 00:37:30.480
listless flavors or and now nowadays class
has a lot of the things that you

392
00:37:30.559 --> 00:37:36.519
get in Ruby, and I suspect
that that's where some of that came from.

393
00:37:37.360 --> 00:37:39.960
Is probably looking at list and saying, oh, yeah, that that

394
00:37:40.079 --> 00:37:52.639
works. So how the oj jem
differ from what the built in Jason passa

395
00:37:52.800 --> 00:37:57.239
in Ruby? Is the Ruby one
the one in the standard library gina.

396
00:37:57.360 --> 00:38:00.280
Is that written in Ruby? Or
is that a C extension? Because I

397
00:38:00.280 --> 00:38:02.480
know OJ is a C extension,
isn't it? It is, Yes,

398
00:38:02.599 --> 00:38:10.159
there's the Jason jim Originally it was
in Ruby and then with a C extension,

399
00:38:12.039 --> 00:38:15.239
and I think that's still true.
I don't know if the Ruby part

400
00:38:15.239 --> 00:38:20.199
of it is still there. I
think it's all that's the extension. But

401
00:38:20.280 --> 00:38:25.039
we took different approaches to the problem. So, you know, one of

402
00:38:25.079 --> 00:38:30.119
the and I've complained about this before, I should complain, but one of

403
00:38:30.119 --> 00:38:37.760
the things that the Ruby jem encourages
is monkey patching. So basically, if

404
00:38:37.800 --> 00:38:44.239
you want the feature of being able
to decode or encode encode your object,

405
00:38:44.920 --> 00:38:50.480
you basically have to modify the class, which means that if somebody else comes

406
00:38:50.519 --> 00:38:53.639
along and says I want this other
encoding system. Oh and I picked the

407
00:38:53.679 --> 00:38:59.440
same names for incode. Yeah,
now we have collisions because you try and

408
00:38:59.480 --> 00:39:06.079
monkey. Actually one overwrites the other. The approach that I took with with

409
00:39:06.079 --> 00:39:10.840
with OJ was OJ is a separate
package. It'll look at any object.

410
00:39:12.440 --> 00:39:17.119
You don't have to modify that object
to to encode it. You basically leave

411
00:39:17.159 --> 00:39:22.239
the object a lots not yours,
don't mess with it. And that's kind

412
00:39:22.239 --> 00:39:30.159
of the approject too. Yeah,
monkey patching is a bit. Uh yeah,

413
00:39:30.519 --> 00:39:35.840
it's quite divisive. I'm a fund
of it in certain context, but

414
00:39:36.199 --> 00:39:40.679
completely seeing the point you're making there, right, I was hopeful that refinements

415
00:39:40.679 --> 00:39:45.719
would have fixed all of this.
It doesn't quite work the same way.

416
00:39:46.400 --> 00:39:52.639
No, it's a it's a design
decision that was made once you once you're

417
00:39:52.639 --> 00:39:54.840
down that road. Yeah, you
can't really have it both well, you

418
00:39:54.880 --> 00:40:01.079
can have it both ways, but
some things you can't change. Yeah,

419
00:40:01.079 --> 00:40:07.760
that's one thing I missed from other
languages is method overloading. And for this

420
00:40:07.840 --> 00:40:15.599
reason, right, it makes it
very hard to do it with that monkey

421
00:40:15.599 --> 00:40:22.119
patching, to be honest, right, Yeah, I can plug for WISP

422
00:40:22.199 --> 00:40:27.400
and flavors is before and after and
whoppers. It was nice and you could

423
00:40:27.440 --> 00:40:30.719
basically say before this gets called,
do this, or after it gets called

424
00:40:30.760 --> 00:40:37.639
do that, so you can avoid
the monkey patching issue. This is really

425
00:40:37.639 --> 00:40:43.400
cool, all right. So if
somebody wants to benchmark their you know,

426
00:40:43.440 --> 00:40:46.679
web processes and like, do a
comparison, like, say I have a

427
00:40:46.719 --> 00:40:52.000
Sinatra app that I want to swap
out, I'll go for ah, what

428
00:40:52.000 --> 00:40:58.280
what's what's your recommended path for that? Do you have tools that you use

429
00:40:58.800 --> 00:41:01.599
to do tests like that? KHM? Well yeah on the web where on

430
00:41:01.760 --> 00:41:05.960
my read me page for I'll go
you see at the very bottom, I

431
00:41:06.039 --> 00:41:14.159
was prefer performance measure basically, and
that's definitely what I would use when I'm

432
00:41:14.280 --> 00:41:19.360
when I'm bencharking by my stuff,
are trying to make improvements on it,

433
00:41:19.519 --> 00:41:22.719
tweak it here, tweak it there. I'll use that to see if I've

434
00:41:22.920 --> 00:41:29.639
been successful or not. Do you
prefer that over like a patchy bench or

435
00:41:29.679 --> 00:41:36.239
something like that. You actually,
I don't know if a patchy bench was

436
00:41:36.320 --> 00:41:45.320
available when I first wrote this but
there is another tool that escapes me.

437
00:41:49.880 --> 00:42:00.320
See if I can recall by looking
at this, Yeah, I don't see

438
00:42:00.320 --> 00:42:07.000
it right now, there are out
there looks very similar to a patchy bench.

439
00:42:08.679 --> 00:42:15.039
I mean you don't have to do
much, but I mean there's only

440
00:42:15.119 --> 00:42:19.800
a certain number of things that you
really want to do, so you give

441
00:42:19.840 --> 00:42:23.440
a few options for how you control
it, the number of workers and requests,

442
00:42:23.440 --> 00:42:29.440
requests per second and stuff like that. There's only so many things you

443
00:42:29.559 --> 00:42:37.559
really want to do. I'm interested
to know, like, because I see

444
00:42:37.599 --> 00:42:42.000
you have lots of middle where uh
set up here to make it easy to

445
00:42:42.039 --> 00:42:46.119
snap and plug into this uh kind
of framework. I don't know if you

446
00:42:46.159 --> 00:42:50.880
want to call it framework. Yeah, I'm not sure what you color.

447
00:42:52.280 --> 00:42:57.079
Uh. But so I'm curious,
like, uh, because I foresee this

448
00:42:57.159 --> 00:43:02.079
as being like something you can quickly
just like a you know, hey,

449
00:43:02.280 --> 00:43:07.800
like try this out and we'll show
you the benchmarks and performance of using this

450
00:43:07.880 --> 00:43:14.400
over something else or uh, you
know, how does is it pretty straightforward

451
00:43:14.400 --> 00:43:21.039
to like connect things to the middleware
in a way like that where you can

452
00:43:21.079 --> 00:43:25.320
get observability or things like that.
Well, for middleware, it just uses

453
00:43:25.320 --> 00:43:32.159
the rack approach. Okay, So
so It's doesn't have any claim to be

454
00:43:32.199 --> 00:43:37.119
in a middleware expert on that.
It just supports RACK. So can you

455
00:43:37.239 --> 00:43:45.480
use this as a RACK middleware as
a RACK serve? Yeah, As a

456
00:43:45.519 --> 00:43:52.840
matter of fact, some of the
examples that do show that. Yeah,

457
00:43:52.239 --> 00:43:55.559
I think it really boils down to
when people are trying to build a Ruby

458
00:43:57.320 --> 00:44:01.920
application web server comes down. Are
you going to go Rails, are you

459
00:44:02.000 --> 00:44:07.920
going to use rack, which is
a little more low level, or are

460
00:44:07.920 --> 00:44:13.320
you going to just do it all
on your own and all of the more

461
00:44:13.400 --> 00:44:21.559
viable options. Do you recommend using
this for like custom sockets? Explain that

462
00:44:21.559 --> 00:44:25.960
one more detail, sure, Like
if I just want to connect on an

463
00:44:27.079 --> 00:44:34.320
arbitrary TCP socket or UDP or something
like that, Oh, yeah, it

464
00:44:34.360 --> 00:44:37.519
does actually support that. It actually
supports a couple of different models. So

465
00:44:37.719 --> 00:44:45.960
for example, I'd say that let's
say you have a Rails application and you

466
00:44:45.039 --> 00:44:52.360
want it to be able to get
data. This is completely contrived get data

467
00:44:53.360 --> 00:44:59.400
by using graph ql and hitting some
other server somewhere else. And then you

468
00:44:59.440 --> 00:45:02.239
could even the same one. You
could even open up a file of scripture

469
00:45:02.599 --> 00:45:08.679
and you saw us your stocket and
cool exchange data that way. So you

470
00:45:08.719 --> 00:45:15.000
know you might set up your I'll
go as your data store, and you

471
00:45:15.079 --> 00:45:17.800
just keep keep a great big hash
map in there, you know, obviously

472
00:45:17.840 --> 00:45:22.920
in memory, so you lose it
if it goes if it goes down,

473
00:45:22.000 --> 00:45:31.920
but you can then connect with a
lower level socket then over TCP and get

474
00:45:31.920 --> 00:45:35.880
your data that way. So I'm
curious, like, h, you know,

475
00:45:35.920 --> 00:45:37.440
how how long has this been out? Like how long are you working

476
00:45:37.480 --> 00:45:40.639
on it? And like what is
you know, how do you get this

477
00:45:40.719 --> 00:45:47.159
out there? You know, like
how does the have you gotten like a

478
00:45:47.159 --> 00:45:52.559
good amount of contributors to it?
And you know, is it pretty pretty

479
00:45:52.559 --> 00:45:55.360
straightforward to manage at this point?
Like it's very well so clean written.

480
00:45:57.719 --> 00:46:00.960
I'm just curious, like, you
know, what experience is, uh work

481
00:46:01.719 --> 00:46:07.280
open source project? Generally, what
I've seen with the open source projects is

482
00:46:08.519 --> 00:46:15.519
you get contributors that want to like
fix a bug or identify an issue,

483
00:46:15.320 --> 00:46:17.719
but they typically don't get in and
say, hey, I want to add

484
00:46:17.719 --> 00:46:22.960
this great this brand new, big
feature. It's typically just a little bit.

485
00:46:23.320 --> 00:46:27.679
You know, you have a spelling
mistake or you know, it crashes

486
00:46:27.719 --> 00:46:30.880
when you when you look at it
backwards, so you know I can fix

487
00:46:30.920 --> 00:46:38.440
that, but you know that's pretty
much the extent of UH contributors so far

488
00:46:38.519 --> 00:46:44.639
on the stuff that I've been working
on. Yeah, I guess the biggest

489
00:46:45.559 --> 00:46:51.280
and it's not really complaint. My
biggest wish for open sources. I wish

490
00:46:51.280 --> 00:46:53.880
there was some way of getting feedback
from people that are using it, how

491
00:46:53.880 --> 00:46:59.039
they're using it, how they like
it. But there doesn't really seem to

492
00:46:59.079 --> 00:47:05.280
be any nice path to do that. There's a nice path for yeah,

493
00:47:05.320 --> 00:47:09.719
here's issues, but there's not a
nice path that says I'm using this work

494
00:47:09.760 --> 00:47:15.519
and great or have you tried using
it in this way? It would probably

495
00:47:15.559 --> 00:47:20.880
be useful for folks, you know, to see how other people are using

496
00:47:21.239 --> 00:47:25.639
different open source packages and see if
it fits any of the things that they're

497
00:47:25.639 --> 00:47:34.079
trying to do. Yeah, I
have been seeing a recent influx in like

498
00:47:35.679 --> 00:47:38.239
open I don't know what they call
it specifically, but basically a lot of

499
00:47:38.239 --> 00:47:45.199
repositorities will turn on by default like
use the analytics and metrics in the libraries,

500
00:47:45.800 --> 00:47:52.280
which you know, maybe maybe isn't
the best solution to this problem,

501
00:47:52.320 --> 00:47:59.079
but right, and there's discussions at
least forget how anyway, there's a discussion

502
00:47:59.440 --> 00:48:07.400
category and I've seen a few a
little bit of that that's on OJ and

503
00:48:07.719 --> 00:48:12.280
I'll go but more on some of
my GO projects, there seems to be

504
00:48:12.559 --> 00:48:16.519
a lot more. I don't know. Maybe it's just a different kind of

505
00:48:16.559 --> 00:48:22.519
crowd that goes to the different types
of languages. I have no idea.

506
00:48:22.159 --> 00:48:25.559
That's funny, Yeah, I mean
I'm curious, like, how do you

507
00:48:25.639 --> 00:48:30.960
like discussions? Like, have you
found certain value in it? O're just

508
00:48:30.000 --> 00:48:35.239
like issues workflow? Yeah, I
have Actually, you know, with a

509
00:48:35.360 --> 00:48:38.199
discussion, you don't have that pressure
to I got to fix this bug.

510
00:48:39.079 --> 00:48:44.400
It can be yeah, what do
you think about this? And it's like,

511
00:48:44.639 --> 00:48:47.400
well, maybe not that. How
about something like this instead? You

512
00:48:47.440 --> 00:48:53.679
know, you get more people involved, so it's yeah, a little more

513
00:48:53.719 --> 00:49:00.800
friendly, I guess, or a
little more less pressure. Less pressure,

514
00:49:00.920 --> 00:49:08.119
Yeah, I can see that.
Ah. But having having said that,

515
00:49:08.719 --> 00:49:13.320
some of the projects OJ, for
example, I've got a couple of folks

516
00:49:13.360 --> 00:49:19.960
that contributed, contribute fairly radio and
find a little tweak here, a little

517
00:49:19.960 --> 00:49:23.760
tweak there, you know, help
make make it a little bit better.

518
00:49:24.760 --> 00:49:29.920
And that's kind of nice. So
what's the release process look like for something

519
00:49:30.360 --> 00:49:34.880
more along the lines of a GOO
where I guess you don't have too much

520
00:49:34.960 --> 00:49:42.280
use case uh, specifically yet.
But you know, do you foresee that

521
00:49:42.360 --> 00:49:46.719
being like maybe a different release process
than something like oj. Uh No,

522
00:49:46.880 --> 00:49:51.320
it's just I try and follow the
same release process, you know, I

523
00:49:51.639 --> 00:49:55.039
put in a I keep a change
log, and try and follow the the

524
00:49:55.079 --> 00:50:05.320
standards for that. I I branch
off of development to make my featured branches,

525
00:50:06.599 --> 00:50:10.519
merge them into development when it's time
for release, excuse me, I'll

526
00:50:10.559 --> 00:50:17.800
merchant to master tag it and then
do the release to use the same practice

527
00:50:17.840 --> 00:50:22.000
across the board. So I can't
help but think, uh, you know,

528
00:50:22.079 --> 00:50:29.599
a goo's the Japanese word for flying
fish, right, And you said

529
00:50:29.599 --> 00:50:35.840
you spend some time in Japan yourself. This seems to follow kind of the

530
00:50:36.039 --> 00:50:42.000
Ruby pattern I've seen more in Japan, where it's you know, very much

531
00:50:42.119 --> 00:50:49.679
less rails heavy and very much Ruby
forward, right Sinatra Definitely, at least

532
00:50:49.760 --> 00:50:53.800
years ago when I attended uh Ruby
Kaigi, you know, Sinatra was more

533
00:50:53.840 --> 00:51:00.679
of the rails type than it was
raels itself, right, Right, So

534
00:51:00.960 --> 00:51:09.920
do you see like maybe more people
from like the source of Ruby, the

535
00:51:09.960 --> 00:51:16.800
origins of it, maybe picking up
see more and jumping on maybe a Goo's

536
00:51:16.800 --> 00:51:24.239
adoption, you know, definitely for
OJ and O X, I think there's

537
00:51:24.280 --> 00:51:29.159
a bigger following in Japan than there
is in the US. I mean,

538
00:51:29.840 --> 00:51:35.760
yeah, this is just based on
issues and PR requests, right, but

539
00:51:36.079 --> 00:51:44.519
it seems to be more active in
Japan. I'll go hard to say that's

540
00:51:45.159 --> 00:51:50.159
that seems to be a little more
international, and maybe that Japan hasn't picked

541
00:51:50.239 --> 00:51:54.519
up on graft you well as lunch. Yeah, but again, you know,

542
00:51:54.599 --> 00:51:59.079
without that feedback from users, it's
kind of hard for me to say,

543
00:52:00.039 --> 00:52:05.199
but I do remember. So the
name a go I came up with

544
00:52:05.239 --> 00:52:09.239
that my wife and I were taking
a vacation on the northern side of Japan

545
00:52:09.320 --> 00:52:16.239
and driving along and you know,
stopped at a little place and I like

546
00:52:16.360 --> 00:52:23.440
dried fish, So got some dried
fish and eating it and thinking thinking about

547
00:52:23.440 --> 00:52:28.599
how I was going to do this. It's browser, and that's when it

548
00:52:28.679 --> 00:52:31.960
was, oh, I'll go flying
fish. It flies yeah, so fast,

549
00:52:32.559 --> 00:52:39.880
So that's great. So that's where
it came from. The epiphany occurred

550
00:52:39.880 --> 00:52:47.679
to driving north in Japan. So
I'm curious too, like, just serving

551
00:52:47.719 --> 00:52:53.360
back to the graph GIL aspect of
this, does it integrate the full graphic

552
00:52:53.360 --> 00:53:00.360
GEL aspect? Is there anything missing
or client library connection wise? No,

553
00:53:00.519 --> 00:53:05.920
it's as far as I know it's
a full spec I'd be interested to know

554
00:53:06.159 --> 00:53:09.199
somewhere. If you find something where
it isn't, let me know and I'll

555
00:53:09.239 --> 00:53:13.960
get it in it. I would
love to see benchmarks of this against the

556
00:53:14.239 --> 00:53:17.239
graph Kilo Rube, because to be
honest, that it could make a great

557
00:53:19.000 --> 00:53:22.480
kind of showcase of Hey, what
use this over that? Mm hmm,

558
00:53:23.199 --> 00:53:34.800
Well, I think I have a
clink web Frameworks the benchmarker. I believe

559
00:53:34.840 --> 00:53:42.159
that compares it to just regular Ruby
graft cullo. Oh okay, I know

560
00:53:42.239 --> 00:53:45.519
that's changed a bit over the years
too, so I'm not even sure where

561
00:53:45.559 --> 00:53:50.599
everything stands. I know I haven't
been updating into my latest versions, so

562
00:53:51.480 --> 00:53:54.400
maybe a little bit long in the
tooth. Hey, I'll give it a

563
00:53:54.440 --> 00:54:00.519
try. So all these the open
sauce pro jecks, would you run with

564
00:54:00.679 --> 00:54:07.960
quite a few of them? Are
they just like hobby projects that do you

565
00:54:07.000 --> 00:54:12.880
take sponsorships from the community, or
are they like for businesses that that that

566
00:54:13.000 --> 00:54:19.559
you walk for a walk with their
hobby projects? Yeah. Originally OJ and

567
00:54:19.639 --> 00:54:23.880
o X were for a company KVH
in Japan. Actually I don't think KH

568
00:54:24.440 --> 00:54:34.039
anymore. I think was subsumed by
somebody else. But otherwise, yeah,

569
00:54:34.199 --> 00:54:43.239
just for hobby. I like writing
code. Fair enough. My relaxing time

570
00:54:43.360 --> 00:54:47.000
is I stopped working, sit in
front of the TV with my wife and

571
00:54:47.280 --> 00:55:04.639
right coach, I love that.
H Uh, your peaceful time, you

572
00:55:04.679 --> 00:55:12.280
know, breaking the Japanese sandgarden,
you know, just pumping out some super

573
00:55:12.320 --> 00:55:16.480
performance code. Uh well, I
do try to get a little base practice

574
00:55:16.519 --> 00:55:23.000
and everyone. Well we've talked about
a lot here. I'm excited to try

575
00:55:23.000 --> 00:55:28.239
out a ton of this stuff and
see how easy you know, grap cool

576
00:55:28.360 --> 00:55:32.239
is working with Ago, because it
definitely that is a great uh use case

577
00:55:32.320 --> 00:55:37.480
for it. Is there anything else
you wanted to talk about? Uh,

578
00:55:37.679 --> 00:55:43.159
you know before we go to two
pics here? Nothing, nothing kinds to

579
00:55:43.199 --> 00:55:45.360
mind. This is kind of a
whole new experience to me. So I'm

580
00:55:46.000 --> 00:55:51.079
sure what what was expected? Yeah, I mean, if anything, get

581
00:55:51.079 --> 00:55:57.760
people exposure to Ago and you know, really lower level service stuff because you

582
00:55:57.800 --> 00:56:01.280
don't need you know, you don't
need too much to get something out there,

583
00:56:01.519 --> 00:56:07.360
and I go, definitely makes it
easy to do and you know,

584
00:56:07.400 --> 00:56:09.960
stick to the basics. Really cool. So we have a segment at the

585
00:56:10.039 --> 00:56:14.719
end here where we kind of just
pick a couple of things or one thing

586
00:56:14.800 --> 00:56:19.960
that could be anything, doesn't have
to be cod doesn't have to be anything

587
00:56:19.960 --> 00:56:22.920
in particular. Just pick something that
you know you want to share with the

588
00:56:22.920 --> 00:56:34.079
world, share with the Rubik community
here. It could be anything. We

589
00:56:34.119 --> 00:56:37.559
can give you some time. We
can give you some time. Do you

590
00:56:37.599 --> 00:56:38.840
have anything you want to share?
I I can go if you don't.

591
00:56:39.519 --> 00:56:45.639
Yeah, I got a couple of
things. One is the TV show Better

592
00:56:45.719 --> 00:56:50.239
called Soul, which I'm binging again
fighting the fourth time, I think,

593
00:56:50.400 --> 00:56:54.239
which is a prequel to Breaking Bad. It's my favorite TV show of all

594
00:56:54.360 --> 00:56:59.159
time, so because I'm binging at
that fall froend of my mind. So

595
00:56:59.199 --> 00:57:02.639
that's one of my pigs. And
the other one is a movie I saw

596
00:57:02.719 --> 00:57:08.360
last week on Netflix called Unfrosted,
which is made by Jerry Seinfeld, which

597
00:57:08.400 --> 00:57:15.360
is the most unbelievably stupid, nonsensical
load of bollocks I've ever seen in my

598
00:57:15.400 --> 00:57:21.360
life. But it was thoroughly entertaining. It's like one of those movies where

599
00:57:22.280 --> 00:57:24.599
I have a couple of glasses of
wine, throw your brain away and just

600
00:57:24.639 --> 00:57:29.599
switch off and watch it. It
is such drivel, but it is so

601
00:57:29.760 --> 00:57:34.119
funny. It's far from a good
movie, but it's one of those movies.

602
00:57:34.159 --> 00:57:39.039
That's good because it's so bad.
That's funny. I'm about to check

603
00:57:39.079 --> 00:57:50.880
that out. That sounds great.
I guess I can go. I've been

604
00:57:52.320 --> 00:57:57.920
playing with a lot of AI stuff
as always lately, and I got I

605
00:57:57.920 --> 00:58:01.159
got the Rabbit R one. There's
a lot of flack out there about it,

606
00:58:01.760 --> 00:58:07.440
and there's something that's not great at
but it does great at transcribing stuff

607
00:58:07.800 --> 00:58:13.119
and using it for that purpose and
summarizing meetings and things like that, so

608
00:58:13.159 --> 00:58:17.320
I am finding like use cases for
it. The vision is a little lacking,

609
00:58:21.079 --> 00:58:24.360
but I don't know, it's kind
of fun. It's it's an interesting

610
00:58:24.360 --> 00:58:29.639
device, so I will plug it. I don't know if it's worth it

611
00:58:29.679 --> 00:58:37.119
for everyone, but I'm having fun
with it and the Yeah. The other

612
00:58:37.159 --> 00:58:46.119
thing, there is a large language
model trainer application where you basically can point

613
00:58:46.239 --> 00:58:52.960
a hugging faced data set at it
and it'll automatically fine tune a model for

614
00:58:52.039 --> 00:58:57.920
you, which is really interesting.
So I've been toying around with that and

615
00:58:58.239 --> 00:59:05.239
playing with stuff train and fine tune
some models based on different conversations, which

616
00:59:05.280 --> 00:59:13.840
is kind of funny. Have you
been using the Apple new Apple Mlex I

617
00:59:13.920 --> 00:59:22.159
haven't, mostly because I just bought
this giant BEF machine running GPUs, so

618
00:59:22.199 --> 00:59:27.280
I'm doing doing running it on GPUs
right now, but I am interested to

619
00:59:27.320 --> 00:59:31.679
check that out. I only have
access to an M two here, so

620
00:59:32.599 --> 00:59:37.559
I don't know how much performance I'll
get out of that. But have you

621
00:59:37.800 --> 00:59:43.119
messed around with that at all?
Yeah, I've bought I've got a studio.

622
00:59:43.400 --> 00:59:49.840
It's an older one. The okay, it seems to run just fine.

623
00:59:50.840 --> 00:59:53.440
Nice. Have you run just inference
on it? Or have you tried

624
00:59:54.119 --> 01:00:00.920
tuning stuff? I've tried tuning,
I haven't tried a full blown training.

625
01:00:00.039 --> 01:00:13.119
That's kind of it's almost why bother? Yeah, done right, that's funny.

626
01:00:13.119 --> 01:00:15.960
I'm curious what you use for your
inference? Do you use like Lama

627
01:00:16.039 --> 01:00:25.840
CPP or have CPP? Still trying
to figure out what's best for what I'm

628
01:00:25.840 --> 01:00:30.280
doing for work at the hospitals who
are trying to we're trying to use that

629
01:00:30.440 --> 01:00:39.280
for various applications that I probably can't
get into. Sure, mhm, well

630
01:00:39.320 --> 01:00:46.119
cool. Do you want to share
some pics, Peter, I guess like

631
01:00:46.320 --> 01:01:01.199
what kind of picks? Maybe one
of the bases on your wall? Listen,

632
01:01:02.440 --> 01:01:06.920
Oh, that is really cool.
If you're not seeing this right now,

633
01:01:07.320 --> 01:01:15.199
it looks to be a custom travel
base. Actually started out so I

634
01:01:15.320 --> 01:01:20.519
was I've been taking bass lessons from
well, actually a guy named Mike mccavanie.

635
01:01:21.039 --> 01:01:25.840
He was the lead guitarist for Gypsy
Rose. But I bought this and

636
01:01:25.880 --> 01:01:30.079
told him I was trying to build
a travel base and he says, Oh,

637
01:01:30.119 --> 01:01:34.599
I've got this old junker here,
all kind of busted up. So

638
01:01:35.320 --> 01:01:42.079
that became the neck. I cut
off the head, made the body and

639
01:01:43.119 --> 01:01:47.960
yeah, you can see behind it. So the strings basically go around,

640
01:01:49.199 --> 01:01:53.639
come up here and go to the
tuning, the tuners so you can adjust

641
01:01:53.679 --> 01:02:02.079
it. This here is for sitting
on your leg. That is so cool.

642
01:02:04.960 --> 01:02:07.719
Yeah, if you can't see this
that the tutors are at the bottom

643
01:02:07.800 --> 01:02:12.559
of the base and there's like a
leg ress. It's really neat. Uh

644
01:02:12.920 --> 01:02:20.039
pretty stoves off so that I can
put it in the back back. Oh

645
01:02:20.440 --> 01:02:23.519
what's the wood that the body is
made of? Oh it's just made of

646
01:02:23.639 --> 01:02:34.960
oak. Okay, that's beautiful.
How long did it take you to build

647
01:02:34.960 --> 01:02:40.400
that? That long? Uh?
You know, off and on over maybe

648
01:02:40.800 --> 01:02:46.239
a month or so. Nice.
Do you have any plans to make more

649
01:02:46.280 --> 01:02:52.280
bases? I don't know. I've
got the other two of our our upright

650
01:02:52.320 --> 01:02:57.519
bases so that you see on the
wall there and I made those, so

651
01:02:58.480 --> 01:03:04.320
there's there's probably another one some we're
in the future. I also build bicycles,

652
01:03:04.320 --> 01:03:07.360
so that's why I could do the
metal work as well as the woodwork.

653
01:03:07.760 --> 01:03:19.440
Nice, the simple stuff. You
know, not even bikes are optimized

654
01:03:19.599 --> 01:03:25.800
enough for you. Actually, I
go the other way on the mis,

655
01:03:25.880 --> 01:03:32.280
I keep it simple. I love
it well. Peter is great talking to

656
01:03:32.320 --> 01:03:36.159
you today. Uh, you know, thank you for sharing your experience.

657
01:03:36.280 --> 01:03:39.480
UH. And I'll go with us. Uh. You know, definitely am

658
01:03:39.480 --> 01:03:43.480
going to dive in myself and see
how fast I can get things to go.

659
01:03:43.880 --> 01:03:46.679
And you know, again, thanks
for all the work that you do.

660
01:03:47.599 --> 01:03:52.880
Appreciate it. I love any feedback. Thanks for having me on the

661
01:03:52.920 --> 01:03:57.000
show. And if anybody wants to
reach out to you or connect with you

662
01:03:57.360 --> 01:04:02.039
on the interwebs, how can they
do that? Email it Peter at older

663
01:04:02.159 --> 01:04:09.079
dot com, O H L A
R dot com. Fantastic h. So

664
01:04:09.360 --> 01:04:13.239
until next time, folks, Uh, Valentino is out of here. Uh

665
01:04:13.360 --> 01:04:19.760
and thank you for listening. H