Hey, everybody, Welcome to another episode of the Ruby Roags podcast. I'm
your host today, Valentino stul. I'm joined by co host I Usual Hey,
and we have a very special guest today, Peter Owler. Peter,
why don't you introduce yourself, maybe tell us a little bit about how you're
so great in the Ruby community and all the lovely stuff you're working on.
I don't know if I can claim greatness, but I started with Ruby quite
a while ago, early twenty twelve, somewhere maybe twenty eleven. I was
a over in Japan, started working for a company KBH, and we're starting
to put together web wealfering and decided the best way to where the best language
would be Ruby. So we started on that and I found out that well,
first of all that the Jason parser was really slow, so I wrote
Jason parser was a bit faster. And years later, after after leaving Japan,
I decided that it would be a good idea to make a more high
performance web server and also stick in to draft you ol, which had started
to become popular at the time, and the rooview offering I was pretty pitiful,
actually, so I try to make some to know is easier to use
and higher performance. And that's I'll go so real quick. Just when you
say Jason parser, you mean the ojjem right, yes, exactly. I
think it's very popular and that's kind of come the de facto, at least
in my opinion, of which Jason parsa to use for its speed and performance.
So I think that's good to clarify. So I'm super interested in this
Ago web server. It is a web server, right, like it is
a web service pretty awesome. So you have a ton of benchmarks on here,
which is kind of incredible. Do you want to just kind of like
walk us through the high level like why use this over you know, even
Sinatra or something like that, right? Well, I mean Sinatra has been
around a long time and it works fine, but its focus wasn't so much
on performance as it was on maybe ease of use or you know, getting
things to work, because it was it was an early system. It's all
written in Ruby, which you know, it's great writing Ruby. I like
write in Ruby. But if you're going to go for performance, you need
to make a cet extension too, Yeah, to get all the all you
can out of it. And that's again that's part of the reason that i'll
go came about so in terms of Sinatra, Uh works great. If you
want a bit higher performance, then i'll go is probably the way. If
you're going graph q WEL, I would definitely suggest i'll go, just because
the the current offering with Ruby for for graph ql is much harder to work
with with. With i'll go, all you have to do is basically say,
here's my class. As long as it implements, uh, the appropriate
method, then you're off and running. Honestly, I I really love this
use case. If talking yeah graph col I've been looking for like just drop
in, Hey, I want to use graph QL and Ruby, and uh
there's like you know, you can use it in a reils context with graph
cool ruby JEM. Uh is that what this is using under the hood or
is it it's customer implementation that's awesome all retinancy. Yeah, so this is
super appealing to me. I'm gonna have to give this a try. Uh
what uh what sparked kind of like do you are you like graph q L,
like you know we should use this for most things? Or what sparked
the need to start here? In my work? I started to use graph
ql and uh again found most of the implementations the APIs are very clunky order
to use. So I wrote something for I'll go, and I also wrote
something for go both. We'll try to make it as easy to use as
possible, again not not requiring a whole lot of wrappers and build up,
but basically just pointed at the class you're interested in exposing as a graph kol
object, and you know, I want to run its course. And that
was kind of the approach. I wanted something that I could use that was
well, that was easier to use, and I go as a rock compliant
right, so you can use it with any any RACK app. Yes,
exactly cool. It actually has some other features as well, as you may
it might be where a graph well also does push. And we were trying
to myself and another fellow, we're trying to get well API, especially update
the specification for Rack to support that, without much success. We went back
and forth the number of times, and there were enough people that were not
interested in seeing that or didn't want to have the API extended that it never
made it. But it's available in a GO. That's awesome. I mean
I was looking at the some of the documentation here on the graph cool stuff.
And it seems to support subscriptions, which is really interesting. Yes,
that's what I was referring to. Yeah, gotcha, So, like,
how does I'm curious for those that don't know, graphical subscriptions are way to
kind of stream responses. Uh so, how does that kind of work under
the hood? Uh? Use, Well, you can use a number of
implementations web sockets as well. My preferred choice if you're using browser, if
you're if you're trying to set up an out of banned subscription, and I
typically use something like gnats, which is a messaging system. And so is
the key feature of AGO? Is it high performance or is it graph ql
or is it both? Yes, it's both, okay, high performance and
easy to use graft quel cool. So like if I was approaching it like
an idiot and say say that, I'm said idiot who builds rails apps,
simple rails crad apps, and I used Puma. What's the reason for me
to drop Puma for Ago? Or is that? Is that not the right
use case for it? So say that again? Maybe? So like,
Okay, so I just built rails apps, I build crad rails apps,
and I used Puma as my web server. So if you were explaining it
to an idiot in this case me, what's the reason to drop Puma for
Ago or is it not the right use case for Ago? It depends on
the the amount of well a man of a question get is if you need
something higher performance, then you might go with a Goo. If you wanted
to step into the graft uel world again, I'll go and with Ago.
That I wouldn't need like uh enginets or Caddie reverse proxy in front of Puma.
I'm guessing because that's the usual set up with reels, isn't it.
You have a reverse proxy because Puma is not very performance, so you need
like a web server in front of it to serve static assets and stuff.
But I'm guessing with I Goo, that's not a problem. That's right,
exactly true. One of the Ago also does support having multiple workers in in
separate h and I want going to say separate threads and separate worked applications.
The well, the advantage of that, of course is is you get around
the GVO lot that you have with Ruby because you can have a number of
workers all turning away at the same time. The problem is that if you
have shared data and access in that shared data. Typically a database has overhead
in itself as opposed to having everything in the same process, like within a
hash map or something like that. So it's a trade off, and you
have to look at your application to decide if you if you are interested in
in uh in just starting out with graft cool and want a nice example I
do. I did write a paper for what was it, uh app signal?
Okay, it's called well, it's a song application. If you're on
the read me page or I'll go, you'll see a reference there under the
news and it's the second news item. But that walks you through it.
Yeah. Yeah, I've never seen graft yell before. I don't know what
I'm doing here. We go here to do it? M hm yep,
I see that there. I'll give that a read a bit later on.
So what is it that makes I go so high performance? Is it just
the fact that it's written in C or is there something other, something else,
a bit clever going on. Of course, there's something more clever has
to be languages. Languages aren't what give you the performance by themselves. What
they do is they give you the means to make something faster. So there's
less overhead in c than there is in Ruby. That doesn't mean just because
you write it and see that it's going to be faster. I've seen plenty
of code that's written in CEE that is the basmally slow. One of the
one of the things that al Go does is it uses multiple threads. Now
that's a problem with Ruby because multiple threads means you've got to keep handing over
the GVL, which there's overhead in that. With all Go, what happens
is the request comes in, it gets put on a queue, that que
gets picked up by nd number of worker threads. They process the request,
and it's only when it gets to the well, the very end where it
hits the Ruby side again, where it gets the GVL, does the work,
gets the response, gives up the lock, and then sends a response
back to their request. So probably ninety percent of the work is done outside
of Ruby. This reminds me a lot of Shopify's pitchfork. Are you familiar
with that? I'm done, No, I know what shopify is, but
pitchboard they've been trying to I think they've actually switched to using this, maybe
not for their main monolith. But it's a bit it's like a forked architecture
hd t B server. It sounds a little bit similar. Yeah, that
happens at a different level with I'll go the It has workers and those are
basically forks of the whole process. Within each one of those forks, there's
still multiple threads that are processing the HGP requests before it basically gets to the
Ruby part and says that Ruby park, do your thing, get the response,
and then again it leaves the Ruby part alone and jumps back into multiple
threads. Gotcha, and what's using? What are you using for the queuing
system? Of course, of course performance what performance is of utmost importance.
You always write your own pretty much, so, I mean, I would
love to dive into some of these benchmarks. So you have a ton of
benchmarks here in your repo. You give one for a reels context as well.
You know, how does it stack up? Let's say, you know
at I use this point, you know, how does it stack up for
a reels app running Puma? Like, what are how are the benchmarks?
You know, it's been quite a few years since I did the benchmarks.
I don't remember what real what I was using with rails at the time,
whether it was Puma or something else. I didn't see big differences though the
benchmarks were done with a single I guess they're done in a couple of different
ways, but in general not with most workers, because with workers and you
have to worry about the overhead of the shared data star, which is typically
quite a bit higher than what you get from the web servers themselves. Gotcha,
Yeah, I mean, I'm just I keep circling back to the one
hundred thousand requests per second and then that kind of like you mentioned, you
know, hitting the limitations of Ruby's benchmark because it goes so fast. Can
you elaborate kind of on on that, right, So your test tool has
to be faster than what you're testing. So the original or what I was
originally using for the Ruby benchmarks wasn't able to keep up with the rates.
So I had a I knew I could go or I knew I could process
more data than what was what the benchmarks were showing. So I tried on
my own and was able to get a significant boosting and throughput or measured throughput.
How do you know that? I'm curious, like, where do you
get to your point where you're like, like, I know you start Yeah,
if you start up, well, a webster is kind of unique because
it can have requests coming in from multiple sources. So if I started up
two, three, four benchmarking tools and were able to hammer on, I'll
go and see that all three of those benchmarking tools were pegged out, and
I knew it to handle more than than each one of those individuals. And
what what protocols does this currently support? HGP? Oh no, it's just
h GPH and HPS. It has not been upgraded to use HP two yet,
so it doesn't handle some of the more well, some of the newer
features. And what about web sockets? I'm guessing if you have graph cuel
screaming as you said, then it's about web sockets as well. Right,
it does support web sockets yess so school, So what are I'm curious?
Like the real live you know, how's it? How's it handling in production?
Right? Like? Are you running this in in production? Are you
using it for like massive scale yet? You know? How is it faring?
Yeah? I you know, I have to just rely on the users
to tell me that. And as you may be, whereas open source projects
typically don't get a lot of feedback except for issues. So you get complaints,
but you don't get any of the any of the things that say,
hey, it's doing great, Yeah, I like it a lot, or
something like that. It's more about issues. Often they start out with I
really like it, but yeah, I mean, honestly, this is like
a I love like Again, it's circling back to graph cuel like I feel
like as like, uh you know, it's I'm torn because on one hand,
most Ruby apps are are going to be using rails in some capacity for
their data connection, right uh, and so it would be nice to just
like quickly get a graphic el sever up and running in a reels context.
Is it fairly straightforward to like connect all those pieces together and mount this uh
like on its own uh like on its own subprocess from rails or or FORDD
process? What what is like kind of like that path look like success?
I haven't. I haven't done a lot with rails myself, okay, as
you might. As you know, it's not a high performance system, so
I tend to steer away from it. I'm curious then, if you if
you're not using rails, what is your preference for like database in combination with
the graph kill side. I have a feeling that will be the bottleneck right
most of quite honestly, I'm doing most of my latest work and Go,
but the databases I'm typically using are either Mango or redist. Okay, do
you find that either of those would be like probably most performance alongside of I'll
go. It depends what you're trying to build or what you're trying to store.
Uh. Reddis is probably high performance or higher performance, but it's a
little bit more restricted than what you can store or how you store it in
there. Mango gives you a lot more flexibility in terms of querity capabilities.
And yeah, I'll admit it's been a long time since I've used Mango.
Uh, I'm curious, you know, since since you have experienced with that,
Like, how how is the pace kept up for the for Mango?
Is it's still like fairly performant. Oh? Yeah, definitely, it's only
getting better. I forget why people decided to switch off of it, to
be honest, yeah, I don't know why they would. We're still using
it quite heavily and in both in Go and in Ruby. But for Ruby
it's kind of nice because you store everything in Jason's So you take your Ruby
object you encoded and just Jason and you store it, fetch it back.
Yeah, I mean, I remember you ready to go. I remember my
first Reels comp It was wildly popular, definitely amongst groupon as an example,
which you know as much smaller now and living social used to be a thing.
I don't know if they're still around, but right I don't know why
Mango kind of dropped off the Reels and Ruby ecosystems. It's definitely not as
prominent, but I always liked it because you could just like dump data at
it and it could handle it right exactly. Yeah. It reminds me.
I have a friend that's uh he loves couch TB for the same reason.
He's just like, you know, relax, just get just go into the
couch. That's funny. Uh So that's interesting. So I'm curious, like,
then, do you find it kind of like a easier to connect graph
col like typing system because you're using Mango in those cases because it's so flexible,
And then I imagine the data structures are similar the uh well for graph
col. The way I'll go works is that data structures are just Ruby objects.
So yeah, it's easy. It's a Ruby object is easily encoded in
Jayson, which is easily stored in Mango and vice versa. That's really easy
to say. Yes, it makes it easy to say, hey, get
me all my all my songs, and you just do a query on the
song database in Mango and there they are. You pull them back out and
they're already decoded and your work is done. Oh that's really cool. I'm
looking at your example now with the artists and everything. Uh oh that's really
cool. Yeah. Oh man, I'm happy to be with this more so,
I see you have locks in in your mutations, all right it I
I imagine there's a lot of like internals happening in i goo that requires locking
mechanisms. Actually, those locks are are simply because you're well, because you're
getting h fee requests. It allows you to have multiple requests in process at
the same time. Oh I see now, so while i'll go can handle
that nicely, the Ruby side of things can't. So it may it may
fire off multiple requests for the same object. So unless you put a lock
on the resource, then now you're liable to get collisions. Well, this
is really interesting because one of my biggest complaints of like rails and like a
background queuing processing system is like you have to like load your entire application just
to run a worker, which seems like so bizarre to me. Which I
know there are like some optimizations that are made right on the on the constant
loading side to help ease the pain of that, which has gotten better,
but it's still like not ideal. Does does AGO kind of like help with
that? Like have you have you had a good experience like with like background
workers, and I go, like as a as an ecosystem, couple with
the database. It works great. You can get very high throughput and your
bottleneck becomes a database, which is kind of what you want, you know,
you don't want the bottleneck to be your application the you know. One
of the things that I I did notice early on was that the rails is
great for putting together prototypes and you know, for setting up you know,
I want these windows to display my data. Fantastic, But if you're looking
for high performance, you know, down the road, it becomes more and
more difficult to get that performance with with the rail, with the rails layers
on top of it. So if you can break your application up to have
a high performance back end and with you know, something that does just the
view making use of RAILS. That seems to be a good way to make
it work. So when when you're writing web applications with I go, do
you use any framework or do you just write like rock good? Uh,
directly for the server, I don't even use rack. You're going down a
level even fatter than that then, exactly. Yeah. The only thing I
struggle with is, yeah, I'm not very good with making pretty UIs and
dealing with CSS and that kind of thing. So yeah, it'd be nice
to have somebody hold my hand on that. It's kind of what rails does.
But yeah, I'm curious, I'm curious what you're like what your bottlenecks
were like in Ruby itself, right, Like what kind of like when you're
trying to test or like hit the limits of the performance, like aside from
the GVL, like what like kind of bottlenecks where you're hitting just like in
the Ruby ecosystem to push things further the Uh So, it's a web server
and the first thing it does after it gets well after processes or requests and
gets on too, and it calls into Ruby. After that, you know,
I'm kind of hands off. It's whatever the you know, whatever the
application developer has written that's going to be have the impact on the performance.
So really I just care about getting stuff into and getting the results back.
So if you've got a a large Ruby result and you want to convert that
to Jason, that'll take some time. Even with Okay, it's still more
overhead than just saying here's a bunch of texts. Right, So are you
not doing any like connection pooling or anything like that to like keep the connection
open with you know, for multiple requests kind of thing. Oh? Yeah,
it does. It does keep the connection open, Okay, and you
can set the time out so that you know after I mean, it'll it'll
drop it. There's no activity. Do you have any examples of like real
world usages where where y'all using I go and it's solved problems that couldn't be
solved in another way. Yeah, you're asking one person. I wrote the
tools. I'm curious where like you want to take take this too? Right?
Like, uh, I can imagine a whole bunch of use cases for
it myself, But do you have any like direction that you plan to continue
pushing it to or I don't see pushing it in any particular direction right now.
It's it's kind of stable the way it is. I guess the next
step would be you know, web two, but I haven't heard anybody really
complaining a lot about that. Yeah, I mean, all I can think
is people trying to hook this up to action cable or or I guess,
I guess, uh, probably any cable at this point. Yeah. I
think the biggest uh, I think the biggest advantage of having ah GDP two
support would be just multiplexing, because you can if you're requesting assets, then
you can send multiple assets down the same TCP connection, whereas with ah GDP
one point one they're all individual requests. I think for like web application developers
like myself, that's been the biggest attraction to h GDP two. It is
just multiplexing, right And of course with ago it's connections are pretty cheap.
You could actually open up multiple connections to a GOO and it'll process the requests
in parallel. And I have seen some people that is that processed fairly straightforward,
just like opening up new connections to it. Yeah, just open up
a connection connection, Yeah, yeah, the bottleneck with the bottle neck that
multiplexing salts and more on the client side because a bras will learning I think
open uh like six to eight connections at a time, So if you have
a vast number of assets that need to be downloaded, that's going to be
a client side bottleneck, which is what multiplexing solts, because it'll just do
it over a single TCP connection, right right, Yeah, I think that
most machines would have a hard time keeping up with a whole lot more than
six or eight connections, So yeah, yeah, exactly. But yeah,
that's why I don't know the specifics of how the magic that HGTP two does,
but because it does it over a single connection, it can get all
those assets down pretty fast. So that's kind of led to the usage of
things like important maps and things like that. Way you don't bundle your JavaScript,
you have them as like twenty thirty individual files, because suddenly getting multiple
files down from the survey isn't that expensive anymore. Right, there's still a
still overhead. I think we're HDP two helps on that is, if you've
got well, if you don't have let's say you're downloading arch assets you're pulling
them from storage, there's going to be delay as you're pulling each segment of
those, so that lets you and relieve it on the same connection. If
the server can provide the data fast enough so there's no delays, then it
really doesn't provide any advantage over having multiple connections. I mean your pipe is
only so big. Yeah, yeah, that's true exactly. I haven't played
a massive around haven't played around a massive amount with the stuff myself, So
I'm just talking from blog posts that I've read and performance benefits of a c
DP DOO. I'm far from an expert right well, and it's also it
depends on on what you're on. What the application is doing with the data.
Yeah, exactly, it's handling all synchronously, then it really doesn't help
it. If it can handle it asynchronously, then I could definitely see an
advantage there. Oh, so you have an example on service events. Mm
hmm. That's pretty cool. Interesting. So I'm curious. We talked a
little bit before the show about your heavy GO use. Uh so I'm curious
just from your perspective, they're uh kind of you know, where where do
you see like GO as providing more benefit over Ruby and in some of these
performances, uh you know, metrics like why use that a Go over like
a Go web server as an example. Actually, the for the the Go
version, I actually wrote it with as for the company, and they allowed
me to open source it. So it's called giggle h and g g q
L. We just frienctic giggle. But on the other the other side of
that is o j uh. It is o J G o J for for
Go, and it includes Jason Path and and quite a bit of others.
I guess the reason I've been drifting more toward Go other than of course amusing
for the company I work with, is it it is higher performance, and
honestly it's easier to work with a harder team with it. It's a strong,
more strongly typed which helps it. Also, because of the way it's
set up, it's easier to set up packages and have different teams or different
individuals working on different part portions of the code and then bring it all together.
Ah So I see, yeah, I always I did like that about
I only did a small amount of Go development, but definitely the typing was
very helpful for uh you know, for people getting up to speed for things
quickly and they just and for the types and sometimes but I'm curious, like,
you know, what about what about Ruby is limiting for like larger teams,
like working on the same thing. Is it just like the packaging ecosystem
of Go that's more beneficial in that respect? Yeah, I think Go has
a little more it's a little more structured development environment. So there's a lot
of tools that help you measure coverage, measure do benchmarks, kind of enforces
testing. Ruby is well and rightly so it's it's a little more free form.
It's great for small projects. I like it. If I'm writing something
for myself, well, I work in the US in Canada, so I
had a horrible time finding a bookkeeping system that would work. So I wrote
my own, and of course I wrote in Ruby. There's no way I
was gonna attempt that to go. Uhh. Ruby is just easier, more
fun to work with. It just doesn't scale us nicely with with larger teams.
That's fair. Uh yeah, So I'm curious other details, like maybe
uh like about o J specifically, is there something more performant about OJ and
GO over Ruby? Uh? Well, yeah, there's there's less overhead and
creating the objects. I think that's probably the biggest difference. I actually use
a similar approach, a single past parser ah to do the parson, which
helps a lot, a lot of tweaking there trying to figure out It helps
you learn the language a lot when you when you test out different approaches to
solving the problem. Now, the overhead of a function call, the overhead
of a number of arguments, the number of return arguments, passing function pointers,
all those things come into play. I gotcha. So would you say,
like Ruby objects are bloated in comparison, No, it's a uh,
they're different more the mechanisms. I'm just curious. I don't know that.
Yeah. So, so think of you can write C code and you can
have structs, and you know, you can attach functions to them, and
they kind of look like objects. You've got to go and you don't have
to do as much work under the covers to make your objects. You know,
the same thing, though you've got attributes. Uh, the inherence mechanism,
inheritance mechanisms. A little yeah, less, I'd like it as much
as as I do Ruby. But Ruby is much more more flexible and much
more powerful in terms of inheritance and the way you can embed or include code
when you're working. Honestly, it reminds me a lot of Lisp, which
is was my first serious language, you know, past basic that is in
listless flavors or and now nowadays class has a lot of the things that you
get in Ruby, and I suspect that that's where some of that came from.
Is probably looking at list and saying, oh, yeah, that that
works. So how the oj jem differ from what the built in Jason passa
in Ruby? Is the Ruby one the one in the standard library gina.
Is that written in Ruby? Or is that a C extension? Because I
know OJ is a C extension, isn't it? It is, Yes,
there's the Jason jim Originally it was in Ruby and then with a C extension,
and I think that's still true. I don't know if the Ruby part
of it is still there. I think it's all that's the extension. But
we took different approaches to the problem. So, you know, one of
the and I've complained about this before, I should complain, but one of
the things that the Ruby jem encourages is monkey patching. So basically, if
you want the feature of being able to decode or encode encode your object,
you basically have to modify the class, which means that if somebody else comes
along and says I want this other encoding system. Oh and I picked the
same names for incode. Yeah, now we have collisions because you try and
monkey. Actually one overwrites the other. The approach that I took with with
with OJ was OJ is a separate package. It'll look at any object.
You don't have to modify that object to to encode it. You basically leave
the object a lots not yours, don't mess with it. And that's kind
of the approject too. Yeah, monkey patching is a bit. Uh yeah,
it's quite divisive. I'm a fund of it in certain context, but
completely seeing the point you're making there, right, I was hopeful that refinements
would have fixed all of this. It doesn't quite work the same way.
No, it's a it's a design decision that was made once you once you're
down that road. Yeah, you can't really have it both well, you
can have it both ways, but some things you can't change. Yeah,
that's one thing I missed from other languages is method overloading. And for this
reason, right, it makes it very hard to do it with that monkey
patching, to be honest, right, Yeah, I can plug for WISP
and flavors is before and after and whoppers. It was nice and you could
basically say before this gets called, do this, or after it gets called
do that, so you can avoid the monkey patching issue. This is really
cool, all right. So if somebody wants to benchmark their you know,
web processes and like, do a comparison, like, say I have a
Sinatra app that I want to swap out, I'll go for ah, what
what's what's your recommended path for that? Do you have tools that you use
to do tests like that? KHM? Well yeah on the web where on
my read me page for I'll go you see at the very bottom, I
was prefer performance measure basically, and that's definitely what I would use when I'm
when I'm bencharking by my stuff, are trying to make improvements on it,
tweak it here, tweak it there. I'll use that to see if I've
been successful or not. Do you prefer that over like a patchy bench or
something like that. You actually, I don't know if a patchy bench was
available when I first wrote this but there is another tool that escapes me.
See if I can recall by looking at this, Yeah, I don't see
it right now, there are out there looks very similar to a patchy bench.
I mean you don't have to do much, but I mean there's only
a certain number of things that you really want to do, so you give
a few options for how you control it, the number of workers and requests,
requests per second and stuff like that. There's only so many things you
really want to do. I'm interested to know, like, because I see
you have lots of middle where uh set up here to make it easy to
snap and plug into this uh kind of framework. I don't know if you
want to call it framework. Yeah, I'm not sure what you color.
Uh. But so I'm curious, like, uh, because I foresee this
as being like something you can quickly just like a you know, hey,
like try this out and we'll show you the benchmarks and performance of using this
over something else or uh, you know, how does is it pretty straightforward
to like connect things to the middleware in a way like that where you can
get observability or things like that. Well, for middleware, it just uses
the rack approach. Okay, So so It's doesn't have any claim to be
in a middleware expert on that. It just supports RACK. So can you
use this as a RACK middleware as a RACK serve? Yeah, As a
matter of fact, some of the examples that do show that. Yeah,
I think it really boils down to when people are trying to build a Ruby
application web server comes down. Are you going to go Rails, are you
going to use rack, which is a little more low level, or are
you going to just do it all on your own and all of the more
viable options. Do you recommend using this for like custom sockets? Explain that
one more detail, sure, Like if I just want to connect on an
arbitrary TCP socket or UDP or something like that, Oh, yeah, it
does actually support that. It actually supports a couple of different models. So
for example, I'd say that let's say you have a Rails application and you
want it to be able to get data. This is completely contrived get data
by using graph ql and hitting some other server somewhere else. And then you
could even the same one. You could even open up a file of scripture
and you saw us your stocket and cool exchange data that way. So you
know you might set up your I'll go as your data store, and you
just keep keep a great big hash map in there, you know, obviously
in memory, so you lose it if it goes if it goes down,
but you can then connect with a lower level socket then over TCP and get
your data that way. So I'm curious, like, h, you know,
how how long has this been out? Like how long are you working
on it? And like what is you know, how do you get this
out there? You know, like how does the have you gotten like a
good amount of contributors to it? And you know, is it pretty pretty
straightforward to manage at this point? Like it's very well so clean written.
I'm just curious, like, you know, what experience is, uh work
open source project? Generally, what I've seen with the open source projects is
you get contributors that want to like fix a bug or identify an issue,
but they typically don't get in and say, hey, I want to add
this great this brand new, big feature. It's typically just a little bit.
You know, you have a spelling mistake or you know, it crashes
when you when you look at it backwards, so you know I can fix
that, but you know that's pretty much the extent of UH contributors so far
on the stuff that I've been working on. Yeah, I guess the biggest
and it's not really complaint. My biggest wish for open sources. I wish
there was some way of getting feedback from people that are using it, how
they're using it, how they like it. But there doesn't really seem to
be any nice path to do that. There's a nice path for yeah,
here's issues, but there's not a nice path that says I'm using this work
and great or have you tried using it in this way? It would probably
be useful for folks, you know, to see how other people are using
different open source packages and see if it fits any of the things that they're
trying to do. Yeah, I have been seeing a recent influx in like
open I don't know what they call it specifically, but basically a lot of
repositorities will turn on by default like use the analytics and metrics in the libraries,
which you know, maybe maybe isn't the best solution to this problem,
but right, and there's discussions at least forget how anyway, there's a discussion
category and I've seen a few a little bit of that that's on OJ and
I'll go but more on some of my GO projects, there seems to be
a lot more. I don't know. Maybe it's just a different kind of
crowd that goes to the different types of languages. I have no idea.
That's funny, Yeah, I mean I'm curious, like, how do you
like discussions? Like, have you found certain value in it? O're just
like issues workflow? Yeah, I have Actually, you know, with a
discussion, you don't have that pressure to I got to fix this bug.
It can be yeah, what do you think about this? And it's like,
well, maybe not that. How about something like this instead? You
know, you get more people involved, so it's yeah, a little more
friendly, I guess, or a little more less pressure. Less pressure,
Yeah, I can see that. Ah. But having having said that,
some of the projects OJ, for example, I've got a couple of folks
that contributed, contribute fairly radio and find a little tweak here, a little
tweak there, you know, help make make it a little bit better.
And that's kind of nice. So what's the release process look like for something
more along the lines of a GOO where I guess you don't have too much
use case uh, specifically yet. But you know, do you foresee that
being like maybe a different release process than something like oj. Uh No,
it's just I try and follow the same release process, you know, I
put in a I keep a change log, and try and follow the the
standards for that. I I branch off of development to make my featured branches,
merge them into development when it's time for release, excuse me, I'll
merchant to master tag it and then do the release to use the same practice
across the board. So I can't help but think, uh, you know,
a goo's the Japanese word for flying fish, right, And you said
you spend some time in Japan yourself. This seems to follow kind of the
Ruby pattern I've seen more in Japan, where it's you know, very much
less rails heavy and very much Ruby forward, right Sinatra Definitely, at least
years ago when I attended uh Ruby Kaigi, you know, Sinatra was more
of the rails type than it was raels itself, right, Right, So
do you see like maybe more people from like the source of Ruby, the
origins of it, maybe picking up see more and jumping on maybe a Goo's
adoption, you know, definitely for OJ and O X, I think there's
a bigger following in Japan than there is in the US. I mean,
yeah, this is just based on issues and PR requests, right, but
it seems to be more active in Japan. I'll go hard to say that's
that seems to be a little more international, and maybe that Japan hasn't picked
up on graft you well as lunch. Yeah, but again, you know,
without that feedback from users, it's kind of hard for me to say,
but I do remember. So the name a go I came up with
that my wife and I were taking a vacation on the northern side of Japan
and driving along and you know, stopped at a little place and I like
dried fish, So got some dried fish and eating it and thinking thinking about
how I was going to do this. It's browser, and that's when it
was, oh, I'll go flying fish. It flies yeah, so fast,
So that's great. So that's where it came from. The epiphany occurred
to driving north in Japan. So I'm curious too, like, just serving
back to the graph GIL aspect of this, does it integrate the full graphic
GEL aspect? Is there anything missing or client library connection wise? No,
it's as far as I know it's a full spec I'd be interested to know
somewhere. If you find something where it isn't, let me know and I'll
get it in it. I would love to see benchmarks of this against the
graph Kilo Rube, because to be honest, that it could make a great
kind of showcase of Hey, what use this over that? Mm hmm,
Well, I think I have a clink web Frameworks the benchmarker. I believe
that compares it to just regular Ruby graft cullo. Oh okay, I know
that's changed a bit over the years too, so I'm not even sure where
everything stands. I know I haven't been updating into my latest versions, so
maybe a little bit long in the tooth. Hey, I'll give it a
try. So all these the open sauce pro jecks, would you run with
quite a few of them? Are they just like hobby projects that do you
take sponsorships from the community, or are they like for businesses that that that
you walk for a walk with their hobby projects? Yeah. Originally OJ and
o X were for a company KVH in Japan. Actually I don't think KH
anymore. I think was subsumed by somebody else. But otherwise, yeah,
just for hobby. I like writing code. Fair enough. My relaxing time
is I stopped working, sit in front of the TV with my wife and
right coach, I love that. H Uh, your peaceful time, you
know, breaking the Japanese sandgarden, you know, just pumping out some super
performance code. Uh well, I do try to get a little base practice
and everyone. Well we've talked about a lot here. I'm excited to try
out a ton of this stuff and see how easy you know, grap cool
is working with Ago, because it definitely that is a great uh use case
for it. Is there anything else you wanted to talk about? Uh,
you know before we go to two pics here? Nothing, nothing kinds to
mind. This is kind of a whole new experience to me. So I'm
sure what what was expected? Yeah, I mean, if anything, get
people exposure to Ago and you know, really lower level service stuff because you
don't need you know, you don't need too much to get something out there,
and I go, definitely makes it easy to do and you know,
stick to the basics. Really cool. So we have a segment at the
end here where we kind of just pick a couple of things or one thing
that could be anything, doesn't have to be cod doesn't have to be anything
in particular. Just pick something that you know you want to share with the
world, share with the Rubik community here. It could be anything. We
can give you some time. We can give you some time. Do you
have anything you want to share? I I can go if you don't.
Yeah, I got a couple of things. One is the TV show Better
called Soul, which I'm binging again fighting the fourth time, I think,
which is a prequel to Breaking Bad. It's my favorite TV show of all
time, so because I'm binging at that fall froend of my mind. So
that's one of my pigs. And the other one is a movie I saw
last week on Netflix called Unfrosted, which is made by Jerry Seinfeld, which
is the most unbelievably stupid, nonsensical load of bollocks I've ever seen in my
life. But it was thoroughly entertaining. It's like one of those movies where
I have a couple of glasses of wine, throw your brain away and just
switch off and watch it. It is such drivel, but it is so
funny. It's far from a good movie, but it's one of those movies.
That's good because it's so bad. That's funny. I'm about to check
that out. That sounds great. I guess I can go. I've been
playing with a lot of AI stuff as always lately, and I got I
got the Rabbit R one. There's a lot of flack out there about it,
and there's something that's not great at but it does great at transcribing stuff
and using it for that purpose and summarizing meetings and things like that, so
I am finding like use cases for it. The vision is a little lacking,
but I don't know, it's kind of fun. It's it's an interesting
device, so I will plug it. I don't know if it's worth it
for everyone, but I'm having fun with it and the Yeah. The other
thing, there is a large language model trainer application where you basically can point
a hugging faced data set at it and it'll automatically fine tune a model for
you, which is really interesting. So I've been toying around with that and
playing with stuff train and fine tune some models based on different conversations, which
is kind of funny. Have you been using the Apple new Apple Mlex I
haven't, mostly because I just bought this giant BEF machine running GPUs, so
I'm doing doing running it on GPUs right now, but I am interested to
check that out. I only have access to an M two here, so
I don't know how much performance I'll get out of that. But have you
messed around with that at all? Yeah, I've bought I've got a studio.
It's an older one. The okay, it seems to run just fine.
Nice. Have you run just inference on it? Or have you tried
tuning stuff? I've tried tuning, I haven't tried a full blown training.
That's kind of it's almost why bother? Yeah, done right, that's funny.
I'm curious what you use for your inference? Do you use like Lama
CPP or have CPP? Still trying to figure out what's best for what I'm
doing for work at the hospitals who are trying to we're trying to use that
for various applications that I probably can't get into. Sure, mhm, well
cool. Do you want to share some pics, Peter, I guess like
what kind of picks? Maybe one of the bases on your wall? Listen,
Oh, that is really cool. If you're not seeing this right now,
it looks to be a custom travel base. Actually started out so I
was I've been taking bass lessons from well, actually a guy named Mike mccavanie.
He was the lead guitarist for Gypsy Rose. But I bought this and
told him I was trying to build a travel base and he says, Oh,
I've got this old junker here, all kind of busted up. So
that became the neck. I cut off the head, made the body and
yeah, you can see behind it. So the strings basically go around,
come up here and go to the tuning, the tuners so you can adjust
it. This here is for sitting on your leg. That is so cool.
Yeah, if you can't see this that the tutors are at the bottom
of the base and there's like a leg ress. It's really neat. Uh
pretty stoves off so that I can put it in the back back. Oh
what's the wood that the body is made of? Oh it's just made of
oak. Okay, that's beautiful. How long did it take you to build
that? That long? Uh? You know, off and on over maybe
a month or so. Nice. Do you have any plans to make more
bases? I don't know. I've got the other two of our our upright
bases so that you see on the wall there and I made those, so
there's there's probably another one some we're in the future. I also build bicycles,
so that's why I could do the metal work as well as the woodwork.
Nice, the simple stuff. You know, not even bikes are optimized
enough for you. Actually, I go the other way on the mis,
I keep it simple. I love it well. Peter is great talking to
you today. Uh, you know, thank you for sharing your experience.
UH. And I'll go with us. Uh. You know, definitely am
going to dive in myself and see how fast I can get things to go.
And you know, again, thanks for all the work that you do.
Appreciate it. I love any feedback. Thanks for having me on the
show. And if anybody wants to reach out to you or connect with you
on the interwebs, how can they do that? Email it Peter at older
dot com, O H L A R dot com. Fantastic h. So
until next time, folks, Uh, Valentino is out of here. Uh
and thank you for listening. H