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