Hey folks, welcome back to the Ruby Rokes podcast.
This week, on our panel we have Valentino Stole and now I'm Charles Maxwood from top End Devs. Go check out my latest and greatest at AI for Ruby dot com. We have a special guest this week and that is JP Kamara. JP, you've been writing about concurrency.
We were chatting before. You live back East.
I don't know if you want to go into more detail than that, but yeah, well maybe you should give us just a little.
Bit of your background.
And we invited you for Ruby Concurrency series, so if there's a story behind that.
I'd love to hear that too.
Sure.
Yeah, thanks for having me. Like I said, I'm JPI Kamara.
I'm yeah. I live in Rhode Island. It's on the East Coast.
I'm a principal engineer at a company called Walthbox, and I've been doing Ruby development for about I've been developing for like sixteen seventeen years, but I've been doing Ruby development for about twelve years, and some other languages mixed in there as well, and so I write technical blog posts over at jpcimara dot com and for the past year actually I started about a year ago writing a series on Ruby currency something concurrency in general, something I'm
super interested in, and I've wanted to create like a great in depth resource for the Ruby community. And so as a result of doing that as well, I ended up contributing a bit to the GVL Instrumentation API. I contributed the mac os support. Yeah, so I've done a little bit with that. So I've worked a little bit with Jean Busier and Ivo Angoe with his GBL tracing gem. And i contributed the macOS support for Coeci's mn thread scheduler for Ruby three point three.
So it's it's been.
Pretty fun, Like I've it's been a lot of work, and I still have a lot left to do, but it's it's taught me a lot. It's allowed me to like contribute to Ruby itself. I've learned, you know, I'm a very terrible C programmer now and so so yeah, it's been an interesting year kind of digging into this. And so about about three months ago I started releasing the first parts of the series and those have been pretty well received so far.
Nice, well, thanks for the work, Yeah, I look forward to benefiting from it.
Yeah, I hope people can like it's I mean, the GVL Instrumentation API. I'm using it like kind of as like an educational resource. That's kind of how I got into it. I was like, Oh, I really want to be able to show people like how threads coordinate, how the GVL plays into that. And Evo, I think you've had on the on the show a couple of times.
His GVL tracing gem creates like a UI layer for that, and so I'm using that as a basis for both using his gem and also creating some like animations of like how threads swap between each other and.
Stuff like that.
So that'll be in my next blog post that hasn't come out yet, which is specifically digging into threads.
Yeah.
Very cool.
Yeah.
Well, and it's funny because you know, you said you've been around the Ruby community for like twelve years. I can't remember how long Valentino has been doing this, but.
You know it's been it's been a while.
Right, I've been doing this, what sixteen seventeen years, and you know I got into programming getting into Ruby, right, So.
Anyway, it's it's interesting because.
I don't think anyone's given a coherent explanation, even back when we were just kind of doing like DRB and threads, given a coherent explanation of Hey, this is what this is and this is.
How it works.
Right, people just complained about the gotchas, Right I tried using threads and oh so bad.
Right, So this is this is very much needed.
The other thing is is that a lot of the naysayers on Ruby uh cite some of the issues with concurrency, and you know, it's like it's like, no, it's it's there, right, if you want to use it, you can use it.
You know.
That doesn't necessarily still make it the best to for every single job, but it does a lot more than you're given a credit for.
So yeah, absolutely, yeah, I mean in terms of, yeah, how people perceive it, you know, there there is a just to go back to like how.
People used to think about it.
I don't remember how many years ago it was, but like I don't know how well and I like it's a pretty well known book, but I don't know if you guys are familiar with Jesse Stormer, I think his
last name is. He created the series called Working with Ruby and so and so he was working with Ruby processes and working with Ruby threads, so like those were sort of my Like I had a lot of experience in other languages with concurrency, but once I came to Ruby, like I didn't do a lot with it at first, you know, I did like rail stuff and everything, and then I ended up reading those books and they really gave me a much deeper insight, and I kind of wanted this to be sort of like a this series
is kind of like a successor to that, and like, in addition, like just more context about it, because it does a good job of kind of explaining like these are the things you can do with threads, and Ruby between threads and processes in particular, gives you the majority of what you need to do any to do anything really, and that's obviously demonstrated by companies handling you know, millions, billions of requests all that sort of stuff.
Like it's very capable and you just have to know how to use it.
And yeah, the great part with his books is they're a little outdated, but like a lot of the core stuff is still there and great and they're all free now too, Yeah, so you can work them on the site. But yeah, it's definitely the concurrency the state of conurrency today in Ruby is is very different. Like there's a lot more education. There's a lot more understanding of how
to handle like threading issues and things like that. There's a lot more deep like embedding of how threading works into a lot of the different tools that we use, like Puma, Sidekick, solid qu all those things. And there's so many great abstractions. A lot of time you don't even really need to use them. You can just use the abstractions, you know, And that's that's sort of what I advocate for a while also just trying to educate on also how to use them and how they.
Work sort of thing.
Can we take a step back?
Sure? Yeah, absolutely, Like I always I.
Always get like I always get thrown by like okay, like what is parallelism, what is concurrency? Like how they're related, how they're not sure you know, and how they like, you know, how the handshake works with the system level stuff right, like each operating system has their own like implementation of like how to you know, process things like how is it all related? Like can we just like identify what we're talking about here?
Sure? Yeah?
And I'm not sure if you're teeing me up for the section of my most recent black post that goes into what is concurrency? Perhaps you are, well, we'll play it if you are. But yeah, so, like there's it's a great point that people kind of throw around the words concurrency and parallelism and they think of them as sort of meaning the same things, and they're they're a
little bit different. But like concurrency is essentially how do I break up a bunch of tasks so that they can kind of work independently, And I can and they can be isolated, and so I can kind of have like a good sense of how to test them in isolation, how to run things in isolation, but coordinate them and but it doesn't really matter like how they actually get
run behind the scenes. So concurrency is kind of how you break up a bunch of tasks that may work together, but it may be that they actually just swap back and forth between each other. So for instance, like yeah, please.
I was gonna I was just going to say, here, we're gonna say for instance, and I was going to say, well, then technically people should be familiar with the idea of concurrency, just with like your job cues on your rails app.
Right, Absolutely, job ques are a perfect example of concurrency because especially in you know, the Ruby version that most of us use, you know, see Ruby. Most you know, Ruby code is constrained by what I don't want to jump too far into this right now, but it's constrained by something so that only one pe of actual Ruby code can run at the same time. And so because of that, most of the jobs you write, you know, what they're really doing whenever they're running, like CPU bound
ruby code is they're they're hopping between each other. It's like I've got job A. It runs for a little bit, Job B runs for a little bit, Job C runs for a little bit. And then where the real value of having threading and Ruby comes from is where you can actually paralyze things. So if we get to the parallel aspect of it, Ruby can't paralyze actual like running Ruby code suit bub bound ruby code, but anything that what's called blocks, like anything that blocks in your code
can be effectively paralyzed. So, for instance, if job A, B, and C all make a query. You know, job A makes a query, it blocks, Job B makes a query, it blocks, Job C makes a query, it blocks. They're all running those queries in parallel, and so A job system is absolutely the like perfect example of concurrency in Ruby, where like, you have these independent tasks that all run and are swapping between each other, and at certain points can actually run directly in parallel, so you can actually
have three things running simultaneously. Whereas concurrency as a as a basic principle, sometimes they run at the same time, sometimes they hop back and forth between each other. The concurrency is kind of that abstraction that lets you not care about it. I write these independent tasks operating system Ruby run time handle this for me, make it parallel sometimes otherwise you know, just hop between them, share resources.
That sort of thing.
Right Does that does that kind of help define it a little bit Valentino.
Or or do you want more on that?
Yeah? Well that's great. I mean I loved how your latest articles kind of summarize it as an orchestrator is being concurrency, and you know, parallelism is more of just like the things running at the same exact time. It doesn't really matter, like you know, there's there's nothing anything waiting for it, so.
Right, yeah, I kind of want to jump in here though, because some people are going to say, okay, well, but why why do I care and why do I need to know about it?
Right?
Because the why do I care might be that it's faster or more efficient or.
Whatever myriad of other reasons.
Right, But then why do I even need to know about it, especially if there is an orchestrator behind the scenes that does it all for me?
M Yeah, that's a good question. I think there's a couple of layers to why you might want to care about it. So the start of the series, I wrote, so you know, the piece we're kind of coming in at for anybody listening to this episode is, you know, we came out at the point of the blog post Ruby methods are Colorless, which talks about how like what the different primitives of Ruby are for concurrency and parallelism, because some things in Ruby can't actually run in parallel and we can talk.
Right, So what is what do you mean by colors? Like, I was curious about this. I love your explanation of your post, but you want to clear that up.
Yeah, absolutely, that's a that's a great point.
So colorless programming was actually a concept I had no idea about a year ago.
Either.
That's kind of like part of what got me going in this whole thing. Is somebody just literally I don't know if you guys have heard of the Prime Egen. He's this like kind of JavaScript personality. And he talked about like colorless programming and go and I'm like, what I was like, I'd never heard that term before. What does colorless mean? Same as kind of you're asking right now?
And so I looked into it, and what really colorless means is that there's some languages that and JavaScript is the example that we use here, but some languages, when you want to do things concurrently or in parallel or whatever, you have to explicitly say like, hey, this piece of code, I want you to do this asynchronous thing now.
And the most common way you'll find in.
Languages is you literally say, like, here's an async piece of code. When I go to run it, I have to tell you I would like you to await this thing to finish, right, and.
So contact Yeah, yeah, my word's not working, but yeah, they have keywords a sync a weight exactly.
Yeah, JavaScript has a sink a weight. Rust also actually has a sinklewight. Python, a bunch of other languages, there's like kind of a fork in some languages have chosen to go a sink a weight, and some languages have chosen to go a different way. And so when you have a sinkle weight, it effectively like I describe it as kind of like infecting your code in a sense. It's like every piece of code that wants to use this asink a weight syntax has to buy into it.
You're always like, it's these layers of like I'm calling a sinkle weight, Okay, the thing calling that has to do a sinkle weight, the think calling that, and the moment you don't do that, you kind of get into this like clunky syntax promises and all that stuff. And so the cool thing about colorless languages and Ruby and some other languages as well is that the run time takes care of that asynchronous behavior for you.
You don't have to worry about saying like I'm about to do this.
I want to do this asyncrenous thing, so I have to know to call await a sinc all those types of things, and Ruby like you say, like I want to call this thing. I want to let's say an HTP request, And so I make my HDP request and Ruby goes like, oh, hey, this is a bocking thing. I'm just gonna tell your thread or your fiber or whatever go to sleep for now. I'll take care of
this for you behind the scenes. And if there's any other threads or fibers running, you know, like if our job example, if there's another job that needs to do something, hey, you can do something now. And so I don't have as a programmer, I don't have to worry about that. I don't have to have that infect my code. And the reason they call it colorless is from an article from twenty fifteen where he referred to like, you have red and blue functions. So hopefully I don't get it wrong,
but red, I think, is the asynchronous function. In blue is your synchronous functions, and so like you end up having this like a coloring of your code. Every ACYNC function is this red one. Every nine a sync is this blue one. And the moment you want to do an ACYNC thing, you have to make your function red. And if that function calling it wants to do an ACINC thing, you make that function red. And so you have this color to your program and this distinct syntax.
And then Ruby you don't have to have that color. In some other languages as well, like Java, actually in fact, is also a colorless language. So so yeah, that's that's the colorless concept.
Not too Yeah, so let's rope this back into Okay, so I don't have to I don't have to color my methods, So why do I care?
Yeah.
So, so the series kind of goes into a couple
of aspects of it. The first part of it is really it's two parts, and it's called your Ruby programs are multi threaded And the thing that I want the point of me writing those articles was part of the series, but also just part of my own interaction with different gems and things over the years that I've had threading bugs in them, because I think it's easy to forget that in almost every programming language you use, behind the scenes, there are there is concurrency happening, whether you want it
or not. Right if you're using Kuma, you've got threads running. You're using Sidekick or a solid q, you've got threads running. Even if you're using like a process based server, there's there's concurrency elements that are running there, and so being away of them helps you write safer code.
So, just as a baseline, just if.
You want to like create code that is safe to run, there's certain things that you need to identify, and to identify those like so for instance, like I go into you know, like global variables, right, it seems so obvious, but there are still there's legitimately still times where I interact with gems and I've submitted some some fixes and stuff for certain gems where there's just global variables being used, and they work fine as long as your threads don't
end up swapping between each other. And so you especially in CEE ruby, like a lot of times they won't swap between each other, and so things seem to be okay, and then you just have these random errors, or you have these random data coruptions, or you have like users data get mixed together. And so part of the reason that I think people should care and should have an understanding about how concurrency works is just for their own just to keep your code like safe and to understand
the principles to keep your code safe. It's actually not super hard to do, but there's certain certain key things that you should understand to keep your code consistent. And on top of that, I know kind of gone long winded on that a little bit. But the other reason to care about the currency is it helps you scale your applications right right, At a smaller scale with applications probably doesn't matter too much if you really understand it.
But as you you know, as you get into like tens of thousands, hundreds of thousands, millions of jobs and requests and things how you tune and how you organize your code and what you call and how what or do you call it, and suddenly starts being really valuable and understanding, like, oh, if I know how a thread works or a fiber works, and I run this code this way, I can scale my application better, right, And so so yeah, that's that's kind of and you know,
the third part for me is just I just find it very interesting. So if you're somebody who just likes reading about interesting things and you like reveal a lot, you know, I find it interesting in that regard.
So so yeah, I love the curiosity by the way.
I feel the same way.
And then I started getting into after we talk to Obie Fernandez on the AI stuff, and I.
Just I can't put it down.
I just I can't make myself put it away.
So sure, and that's one of the the most enjoyable things. Yes, rightest with a piece of programming or a particular technique or whatever.
It's just yeah, it's the most fun.
Right.
But going back to your other point, you know, whether it's Puma or Falcon or something else, you know at your web server or you know, depending on how your job queueing works, you know, whether it's using threads or fibers or processes or something else. And they tend to use them blend of them, actually a lot of them, right, So, so understanding how they orchestrate some of that, Yeah, you can get more horsepower out of your machine.
Absolutely, yeah.
And sometimes you know, like there's there's great abstractions like Falcin or Puma or Sidekick, but even your own code. Sometimes you know, you might be like, oh, like I've got the synchronous piece of code, but I need to like call a few different APIs, right, and if you can, if they're not dependent on each other and you can call them a parallel, it's great to know how to do that, and like what's the best tool to do that?
What are the gotchas?
And you know, I'll get into that like later in the series as well, but like you know, largely, I think.
For like your own code that you're writing.
I tend to say, like, you know, don't thread if you don't have to, because you can you can shoot yourself in the foot if you do. But if you're going to do something that you want to have some amount of like parallelism fr I oh or blocking operations, you know, I tend to recommend like ACYNC because I just think it's a lot more deterministic. So that's like fiber scheduler and that sort of stuff. It's more deterministic.
I think it has better tooling around it. Yeah, and it just there's less of a chance of screwing something up because it operates in a single thread and all that kind of stuff. But yeah, I feel like every time I talk about something, I just sort of trail off at the end.
But here we.
Are, and these are no I'm with you. I've been trying to take on more and more of like doing more things at once, and I'm I'm finding I shoot myself in the foot often because you don't think about like, Okay, well you're performing all these things at once and you're blocking. Now you're waiting for each of those instead of just your waiting for one, and it's more, you know, it's less deterministic the more things that you start to do
in parallel, because more things can go wrong. So I'm curious, like, you know, how do you go about deciding like before you even start like diving in, Like how are you like, okay, well this makes sense, like to run concurrently, like using threads or fibers, Like what are your like decision points for these kinds of of tasks.
Yeah, that's that's a great question. I mean, I think as a base decision, you know. And I had a little bit of a like Twitter interaction about like a recent tweet about somebody suggesting something and realizing it was actually not thread safe and going back and forth a little bit with like Samuel Williams and a couple other people about you know, it's actually best to start off by saying, like maybe just don't like, you know, let let you know, start the baseline you should always start with,
is let's use these like battle hardened great tools that are available in the community, you know, like a sidekick, solid Q good job sort of thing for my background jobs, like a Falcon or a Puma for my server, and start off by tuning those right, That's the first place that I would ever start off tuning something is saying, Okay, like I want to scale up more, what kind of traffic do I get? Do I do? Should I have
more threads? Should I have more processes? That sort of thing, And so, like the first layer of concurrency for me is always just taking advantage of the tools themselves, and then deeper than that, I think is figuring out, well, Okay, within these tools, how can I better split up my work? And so like what I'll kind of get to is really like the lowest level of concurrency for me is the point I get to where I'm like, Okay, now I'm actually going.
To use a thread or acing because I'll use.
That as my last resort, even though like I have a lot of familiarity with it and I do use them. It's it's kind of like, I'll use that as the last piece. Because the best thing you can do, especially if you want to split stuff into concurrent pieces, is to start like utilizing your job system.
Really kind of like like Charles said earlier.
On or you go by Chuck right, Sorry, yeah, no, I feel like I've heard Chuck for years, and for some reason I just looked at mister Charles Maxwett i'll preferred to as. But basically, yeah, you say like, okay, well, now I want to I want to.
Increase my concurrency.
So I might have like particular operations, I'll have more threads in like a Puma or a falcon. But maybe I now then go like, okay, well, now I want to I want to increase my concurrency for my jobs, And so you start to think about, Okay, how do I coordinate these jobs? How do I split them into smaller pieces of work? And so so that's that's kind
of the next layer for me. The first one is I just kind of tweak things about servers, make sure like my throughpit is good, and then I might just start to say, like, okay, this particular job is kind of slow.
How can I break that up?
And so to use Psychic as an example, like Psychic actually just embedded I think iteration support to their gems. So like that's one aspect where you kind of can like split up your work that way. But if you actually wanted to run it concurrently, you know, Psydekic has batches for instance, good job has batches. I'm actually trying to add batched support to solid q as well, because I think it's a really valuable feature. So I have a care submited for that. Yeah, I hope it gets
through soon. And so initially Rosa she was really kind about it. She was like, this is awesome, but we're not going to use it right now, so like if other people want to try it and use it, like we'll we'll kind of evaluate it from there so that.
I think you and I want it.
Yeah, Like batches are awesome because you know, I've used them in Sidechic, but it is a paid feature, and so soliq having batches, I think could be really fabulous for people because then you can say, oh, now I want to break up this piece of work, but I still want to do it in this like in these lanes.
The nice constraints of this framework. So if I break it up and I put it in a batch, and I say like, hey, at the end of this batch, do this thing for me that I can safely coordinate my work and I can split it up into small pieces, you know, And so so that's like the next layer for me, and then the layer after that when you've kind of exhausted your tools and you're like, I really need to do this thing inline it might be in a job, it might be in a web request is
to start saying, okay, I want to use a thread or a fiber or something like that, and that's when generally I would bring in, like I said, like async for myself, right, I would bring in a SYNC and say, like, I want to make these database connections, I want to do these network requests. I want to do file io or even like encryption or something. You know, if you like kind of shell out, you can you can paralyze
that as well. And so I use a SYNC to coordinate that because for one thing, async operates in a single thread, so I don't have to worry about like these weird semantics of threads and like caching at the OS lever level and all this weird stuff. And then and it just has better abstractions, like it's a full featured library versus like threads are a very primitive thing. If I was going to use threads, I would use
like concurrent, Ruvie or something like that. But I would kind of I would say, like probably go with a sing. The point you would maybe need to go to threads we can talk about later, but for the most part,
for your own code. You can usually use a sync but that's kind of my mental model for it, is like, use the tools at the highest level, start splitting up within those tools, and then if I really need to, and sometimes you do and I've I've done plenty of this is split your code using a library like a sink,
where you just have more control. And when I say determinism, what I just mean is like there's very clear, like clear cut points in your acinc code where things will swap out and you can you can know what those are very clearly, Whereas in threads, it's kind of like it's a free fra all, like any piece of your code and a thread can technically swap out at any time, and there's all sorts of gotcha's that can come along with that. Yeah, So that's how I break things down myself.
Do you have any like rules of THEMB for like how many things you do within your acinc calls, Like do you try and like keep like the responsibility low? Like how do you think through that?
Yeah, it's another good question. I think it's partially just depended on I think to your point about like deciding on how much you want to do like part of it is complexity, right, you know, if you're doing you know, and also it's just like the constraints of what you're gonna interact with, right like if I'm gonna if I'm gonna split apart things to try to make like rett
as calls. Let's say, you know, there's there might be an upper limit on how many connections you can even make it once, or API calls there may be an upper limit on how many I can even make it once. But a lot of times for those types of things, like you can you can scale them up pretty high, especially when it comes to a sync because fibers are so light weight and they use such an efficient model
behind the scenes. Like you know, I've written code that's opening up connections to like thousands of things before and it's been fine. But it also I think I think it's probably on like the how like I guess like heterogeneous those tasks are, right, Like if they're all different tasks doing all like different weird things, you probably want to start like coordinating them, splitting them maybe into like multiple jobs to go into each.
Other or something like that.
But you can once you're in it, and once you're doing Nason code, like you can scale it up pretty far, and so the constraints start to become less about your own code and really more about like what can my database server handle, what can the be I'm calling handle? What are their throttles? You know, those types of things,
And so that's when you start coordinating. And and ACYNC does come with some tools that you can say like, hey, I'm going to hand off these tasks and I'll create all the tasks I need, but they're gonna be bound by like a what's called like a barrier. Right, you can say, like there's a barrier of like five and so at once only five will run, and then the next five will run, and the next five run that sort of thing, and so so yeah, like within those I don't the limit is usually imposed for me more
around like what are the external resources? And then I guess to follow upon that. You also don't want to like overload your memory, right, Like so you yeah, you can't. You're not gonna make a thousand requests and then get a thousand responses back and then load them all on the memory and now your server crashes, right, Like you have to you have to be sensible about that.
And actually, I have a.
Chapter or a blog post later on called I think I call it concurrent streaming Ruby, where I like want to go into approaches for how to do things in a more streaming type of way, which I think is valuable, especially when you try to break down tasks and keep your memory low and all that stuff.
So that's your question.
Yeah, I think that you make it like a great points there, and it.
Makes me think smiling inside at somebody dedusting their own.
Oh yeah, yeah, you could definitely do it when you know then you yeah, you want to have some kind of like proxy or some in place, but no matter why, you can definitely ded us yourself if you're not careful.
So that's funny. Yeah, I mean, I think that's a great point in general with concurrency is like it's very easy to eat up resources if you start to like
grow things too big. But it does bring up a good point of like I guess my next topic of discussion, which is like sharing, like data sharing right, like, And I like that you mentioned, uh, you know, using sidekick as like before you get into this space, because I think it does create that separation of data layering that I think is important when working with all of this concurrency stuff in that you give it a task, right, like the data that it needs to operate, and then
it tries to work within it. But that then there's still this weird blurred line. I feel like where Okay, well, you like let's say you drop an ID to a sidekick task and then I use a shared database connection pool to you know, make calls. You know, how does that work in the acink space? And like how do you try and reason about it to make make things not too crazy?
Right? Like?
Yeah, that that is that that's another another great point of like and I will use the sidecake example specifically, and yeah, it's it's kind of like when you the lower you get at every level, you have some amount of shared resources.
Like is the point you're making right?
Like yeah, when I'm at the lowest level, I've got a bunch of threads and they're all like sharing this piece of memory, right, And so they're like, oh, there's like it's so non deterministic and I can overwrite other people all stuff.
That's no good.
But to your point, it's in a way exactly the same. At another level up, I've got a sidekick job. It gets an ID from the database like what is a database.
A database is a shared resource and and actually I think in the second part of the series, I use uh, I think I use Rettis as the example there where I talk about a few race conditions, and so that's kind of what you're you're you're alluding to, right there is like there's even though, like you can't necessarily like when you're doing something in thread you could actually like corrupt memory for instance, like if you were had actual
threads operated at the same time. It's a little harder to do in see Ruby because you've got yeah, like yeah, like especially if you use something like a j Ruby or or a Truffle Ruby or something where like purely parallel you can really corrupt things. But you can definitely do that in Sea Ruby too, and so so like there's that aspect of it. But at you know, at a database level, like actually corrupting it is kind of difficult.
But you can still have of.
Things like race conditions where I go like, oh, yeah, hey, does this thing exist in the database yet? Now it doesn't, so I'm going to add it. And then another sort it is like hey does this thing exist in the database yet? Now I'm going to add it and so you both just like slam into each other. And if you don't have uniqueness constraints for all these things, you're creating duplicate values.
You're overwriting values.
And so there's these race condition things called check then act, which is like I check if it exists, and then I act, And so if you don't coordinate those, you can overwrite each other's data or read, modify, write, where I read a piece of data, I modify it, I write it back. And if a bunch of us are doing that at once, we're all going to be right
and jump to the database. And so it's a great point that even in Sidekick, if you really want to be sure that I'm like operating on this particular ID and it's safe, you probably want to utilize something like a lock, like a database lock, right, And so you know, it's sort of like I guess it's like the concept
like turtles all the way down. It's like it's like shared resources all the ways down where you have to figure out ways to safely share them, and a lot of times, like you know this, this probably comes up more at like a scale, I think, and in scale is relative, right, like it could be ten thousand jobs.
It doesn't have to be a million jobs.
But you know, a lot of times when you're at a smaller level, like locking all the time is not totally necessary. But if you have an ID coming through and you have a really critical piece of data that you want to update, you probably should acquire a lock to that row. And then the first thing you do after acquiring that lock is go like, hey, is this
has this been updated? Does this condition already met? And if it is, you just drop out of the job, right because you the first thing a lock does is it acquires and then reads the row, and so like, you know, I have the freshest data, nobody else can access it. And so that's kind of your your way of core. That's one of the simpler ways of coordinating your jobs is to say, while I'm doing this thing, let me be certain I'm going to lock this row, I'm gonna do my operation.
And then I'm going to move on from there.
So yeah, I feel like I got a little bit lost in answering the question, but but yeah, like that's that's kind of how it would handle it the psychic level. Is there follow up to that?
Ah? So many I feel like this is This is definitely one of like I think the trickiest parts of like Okay, you're foraying into the concurrency realm and then and then you it's like you realize after the fact that it wasn't worth it. Sure, yeah, in a lot of ways, right, Like if I guess it comes back to like, Okay, we'll understand the concepts and know what you're doing before you get into it, but you know, it's hard to also get into it at the same time.
And I think understanding how like you know, what is shared and what isn't and kind of how the messages I guess passed to each other through that orchestration layer is important. So like how do you go about reasoning about that? You know, like as far as like do you have like a very like rigid template for what kinds of data get shared or or.
Don't if we if we were to kind of utilize like the database psychic kind of example again maybe.
Sure, or or even the file system, right, like that's a common one.
Yeah, sure, yeah, that's a good point.
I'll take a step back even actually, and as I'm thinking about it more, you know, I think it's something we take for granted as like we when it's in a job, there is a different set of constraints, but it is actually a similar set of constraints even in a web process, right you know, we a web process even if it isn't threaded, even if it's just processes you're like on Unicorn or pitchfork or something like that,
it's purely just processes. There's no threads. You can have a five different users submit the same update or submit different updates to the same resource at the same time, and how do you coordinate that? So it's sort of like there is a it's you know, the juice isn't worth the squeeze kind of thing, where like you get really deep into concurrency, but you're always kind of thinking about it a little bit and how much does it
matter to you? And I think at a base level a lot of times most things it kind it's it's probably going to sort itself. It's like last one wins whatever, you know, like how much can you actually guarantee And it's really the level of like that and what the importance of that guarantee on the data is For a lot of data, Hey, five people submitted updates, last one one, I don't know like you got five updates. If you have a version system, you can look at the versions
that came through. If somebody right saying they're like, hey, why did this happen, it's like, oh, well, I can see my logs or I can see versions and say like, well, you have five people submit it the last one one.
That's just how it works.
And so then how often does that happen?
Exactly? Not very often. Yeah, And the same can be said about your jobs too.
I think a lot of times, like, really, how often is it that fifteen different updates in jobs happen on the same resource or the same job gets and cued a bunch of times? And there's ways you can mitigate that too, you know, there's like uniqueness gems and stuff
like that for your jobs. And so I think sort of like the way I look at like how to approach concurrency on your servers and your job servers is like the simplest approach wins, which is, unless you're going to corrupt something, the last one wins, and there it is. But then when you have a particular resource that it really just comes down to how important is it that
I exactly get this resource right? And that's when I'll start to apply like a lock or a uniqueness gem or something like that, or a batch process or those sorts of things. So I always try to come at it from an angle of the simplest solution first and then the requirements of how dire it is that my data is always exactly right or it doesn't get coordinated improperly dictate. Yeah, that's sort of the framework for me.
It's like the simple solution wins if we, you know, evaluate the requirements and if there's a requirement that you have to be rock solid about five people can update this and it like complains to four of them, then you do that, you know, and you can add that lock there or that sort of thing, because I think, I mean, honestly, like I think most systems probably have these little like oddball inconsistent pieces of data that come up and you just don't realize it and it just
doesn't matter most of the time, you know, but occasionally does or occasionally it's really important, depending on what industry you're in or what piece of.
Data it is.
So yeah, that's that's sort of my loose framework. I guess the simplicity first, and then based on the requirements and the importance.
Of the data. You start to apply locks and you start to apply other tools.
Are there some tasks where you're like you think right away, like I'm just going to a sync this because then I'll just rip through all these.
I was going to ask that, Yeah, I think a lot of that. Really, I try to evaluate. I try to evaluate like upfront scale of a task, and that will sort of help me dictate how much I want to do. So for instance, like let's say you're you're allowing users to upload like these huge files or something, and you need to do some processing on them well, or like or your constraints are like, hey, I'm trying
to think of a good example. Let's say like people can upload they want to like bulk import data into your system or something, so they can upload a bunch of like CSPs or Excel files or whatever, and depending on what constraints you put on it, like, that's a pretty paralyzable task. And so my first thought for something like that really would probably go to, like, okay, can I like, what's my strategy for uploading these on the front end, and then once it gets to the back end,
I want I know that unless I constrain it. This user could like take down my server, like they send
me a five hundred megaby file. I load the whole thing in the memory, I try to operate through it, and it's like crap, that process just crashed right Well, okay, So in that case, what I probably want to do is I probably want to offload it to a job, and I probably want to try to chunk up that file up front, like the first step of my job, you know, using a batch, I might say, okay, let me split this into five pieces and then run those
in parallel. And that's that's a really nicely paralyzable task. And so there are definitely things like that where like the size of the data indicates to me like I need to do some some ACYNC kind of processing.
And split it up right away.
But you know, if you've got a cred forum and you're submitting five fields, like but whatever, I don't need
to do any special there. But even within that you can get a challenge just too, right, Like maybe you have this like really complicated form and in that case you might not do a sink, but you might try to do like a you know, an insert all and rails or something like that, right, It's like, oh, yeah, I could just insert each record, but I've got fifty different records and now it's going to take three seconds to do like individual steps, so I would do an
insert all and so. But yeah, like there's there's definitely tasks that get presented to you, and the size of your application I think dictates it too, and how many users you have where you're like, yeah, if I had five users, this would scale pretty well if I just did it all here. But now I've got, you know, five thousand users, and so if a bunch of them do this at once, I really need.
To paralyze this.
And I can do it pretty easily using a sink or sidekick or whatever. So there's definitely things we're up front. Like as much as I say simplicity, there's definitely things up front where I'm like, I need to do some streaming.
I need to split this into multiple tasks. I want to use threads and processes and all those things to my benefit so that instead of taking fifteen minutes to process this five hundred MEGABI file, I do it in five seconds or ten seconds, right, And you can do that kind of stuff by splitting this out and it's such a satisfying thing too, right, So, like I think performance, I don't know if about for you guys, performance is like one of the most satisfying things to improve, and
paralyzation can often get you that, you know, at a cost of some complexity. But but it's a good feeling to take something from like five hours down to like two minutes or something, right, Yeah, Yeah, So.
I was gonna say when I when I shave off a couple of milliseconds, I don't always care, but yeah, the five hours to two minutes, it's like I'm a freaking badass.
Oh yeah, that's the best feeling. Oh my gosh.
Yeah, but you're right, Yeah, milliseconds. There have been points in my life where I've cared about milliseconds, but mostly just as like it's probably just like a pride thing. At that point you're like, why is this fifty milliseconds?
Like it should be ten or something. It's like, it does not matter day to day those types of things, unless you're like like a Shopify or something like, Yeah, shaving off forty milliseconds for Shopify probably makes the difference for some things or doing but for most of.
Yeah, it doesn't.
But even then, and it's not the forty milliseconds, it's hey, we saved ourselves, you know, sixty thousand dollars in compute across all of the repluts, Right, that's the big number that gives you the badass feelings, you know what I mean.
That's a good point.
Yeah, you deploy a new version of Ruby with wyj and you get like twenty percent faster. Yeah, you're someone like shop of our GitHub and it's like, well, I just save literally saved us millions of dollars. Right, that's incredible. Right, that's a good point.
Yeah.
I always wonder with like the the you know, the push for serviluss, like you would think that, like you know, your cup, compute time would be like the most important thing at that point, like because because you're you're paying for whatever time it takes for the thing to run, right.
Yeah, But I think it depends it We're off on a tangent, But I think it depends on what what the critical feature is of it, right, And so if the critical feature is something other than the compute time, right, it's accuracy or you know, some other aspect of of what you're doing that affects the user, and the user will spend more with you.
Maybe.
Yeah, Anyway, it's not it's not always one metric and it's not always one metric across the same problem set, so.
Right, And I mean, you know, when you spread things out, even if the added like compute time may seem higher, a lot of times you do end up getting things done faster. So like the sequential version, but I haven't, I personally haven't done a ton of like full servilist stuff. So's it's not something I think about all the time. And the cold starts scaring me so much, So.
I mean, that's that's that's another version of of paralylization though, is the serverless, right, you're just pushing the cloud cloud to it.
That's true, It's yeah, it's kind of like it's again like the layers of concurrency go beyond what a language offers you, and then you start you know, you've got the lowest level, then you've got like processes, then you've got how you coordinate your servers, and yeah, serverleist technical it's like you know, quote unquote like infinitely scalable, right, It's just everything's just popping up anytime you need it. And so there's just more and more layers of what
that concurrency means. But I think for Ruby specifically, you know, you benefit a lot more from tuning at the Ruby level before you get up to higher levels, because if you don't do that, then you tend to you might use a lot more memory, for instance. So like you know, if you don't take advantage of processes and copy on write and stuff like that, then every process is going to take the same amount of memory.
You can't take it.
You can't have any benefit from forking or I think you talked to John Bossier about like Pitchfork on one podcast maybe, and like you know, pitchfork has like reforking, and like you get really optimized memory there. And if you if you try to do things from like a serve purely servilest perspectives, like everything's pretty much taken.
The same amount of it, you can't do anything about it.
Whereas if you if you isolate a little bit more, you can get really efficient memory working on a more isolated level. And then and then it's it's a similar thing to I shaved off thirty milli seconds, Well I should abouf two hundred megabytes of memory right over the over the spectrum of all my processes. Now I get an extra like process or two or three or whatever,
and so now I have more capacity. And processes are one of the best forms of capacity because they have a lot lower latency, which I think is kind of one of the benefits of like a unicorn or pitchfork latency. Process is really good. Yeah, just just it's.
Building on building on top of the idea of like you use what the language offers you, Like you've been getting more involved in the language, right, yeah, and kind of where that is, so like where where does maybe ruby Like where is it missing things and pieces of this puzzle, like what is being worked on that you can like maybe shed some light on that I could use some improvement.
After you answer this.
Sure sounds very like secretive or die or.
I just don't want to use the question.
Answer this question correctly and you'll live blue.
Yeah, yeah, exactly. I feel like like a Monty python. I just got like ejected into the air kind of thing.
So yeah, I I you know, I don't want to I don't want.
To speak too much for the language self, right, Like I'm not a core maintainer or anything like that. I've I've you know, I've I've submitted, you know, I've I've contributed some stuff to the MN thread scheduler. And and there's actually a local guy, Sunghan Jung, who is a he's a student researcher at Brown and he's done some really interesting stuff with ractors. So I've been going back
and forth with him a bit. But to me, I think in terms of the language itself and expanding on that, there's like there's a bunch of pieces in place already that I think just need maybe more like contributor coordination or community involvement or something like that. And in particular, I think those are you know, Samuel Williams is like insane in terms of how much contribution he's done for.
The fiber stuff.
He's right, he goes into like every project and he's like do this, do this, do this, and fibers are work great and then that benefits it. So like fibers are in like pretty good hands with him, and those are going in a good direction. Ractors, you know, I'm sure I believe you've talked to people about ractors before, and ractors are sort of like, you know, they're almost like this like unfulfilled promise. It's like we've all I was like super excited about ractors for RUB three, and
they're just always like not quite there. And so I would like to see more like community involvement in ractors so that people can take advantage of more of that actual parallelism. And I think if ractors got more stable than they are now, people would probably start to like
integrate them more into gems. And then now you have like a truly parallel thing that doesn't take a whole new process of memory, right, because you can do parallel Ruby otherwise, but its processes they use a lot more memory all that stuff, and so with ractors it's a pure parallelism thing. And so I think there's like key inconsistent features in though in those that if those got fixed, we could get maybe more community involvement and we could
expand the area of ractors. The other piece that I think is really thataluable that it was the piece that I contributed to MACO support for is the m N thread scheduler. And so I think the m N thread scheduler is probably one of the most potentially beneficial things to the ecosystem. And the nice thing about it is it can be potentially beneficial without anybody really having to do much of anything. And so the M and thread schedule it basically just says like it operates a lot
more like go co routines. Like in in our go routines and go you have go routines, and like you don't think about threads, You don't think about anything. You just like I just create five million go routines and whatever. They just they just do my work. And so the MN thread scheduler is trying to fill like a somewhat similar role in that it backs itself with some actual OS threads, but a lot of the rest of it
uses the same kind of principle as fibers. They use this thing called a reactor and it uses some like efficient OS processing and stuff.
To handle it.
And so I think if if MN thread scheduling support got really strong, more servers could enable that, and it would actually you would be able to support like the same level of concurrency on existing servers with less threads and so less memory, overhead less CPU, overhead less thread schedule or coordination, and so from an outsider's perspective who's contributed a bit to see Ruby itself, that's probably like
my hierarchy. It's like Samue Williams is doing a great job promoting and doing great stuff with fibers, like that's in pretty good hands. Ractors and MN thread scheduling are kind of like pretty much in Koichi's camp, and I would like to see that get expanded more and that MN thread scheduler get more like full support. We start seeing it used in servers and like being better able
to scale servers. And then kind of the cherry on top to that is if we got better actor support, then people can reach for that and say, I've got this super parallel thing, like I want to do some image processing or something, and I don't want to spend up another process. Whatever I hand it off to. This ractor operates in parallel while I'm doing this other thing. Perfect I've got my parallel stuff in Ruby, And so
those are kind of the three areas for me. Like threading itself is just like a pretty solid long term thing. The MN thread schedule, or if it succeeds, I think, would would kind of take over for that and become like the new default, and it would probably increase the would hopefully increase the performance for a lot of servers. Or at the very least decrease the overhead of those servers. So yeah, those are those are kind of the perspectives
of of seeing the internals of Ruby. I've been trying to read more ractor source code too, to see if I can help with some of that stuff, because I really want ractors to be more stable, and I think like Sung Hung's work. He created a server called Moro,
so we could probably reference that or something. It's like an actual ractor based server, and it's it's sort of like a bit of a toy project, but like the principles could be like kind of powerful for certain things, but because of bugs that are in ractors, it just hit a wall and it hasn't gone any further since then. But yeah, and then threat skied driller fibers. Let's let's get ractors going to that's my answer there.
My follow up question was along some of the same lines.
I mean, you're talking about features that we either have and could use or you know, maybe could I guess become more usable in the future. But I was also thinking along the lines of things like you know, wyget for example, not not in the sense of concurrency, but wyjet was you know, you'd compile with a flag, or you'd you know, you'd turn it on and now you can kind of you can turn it on without using the flag when you compile it, or you can you know,
you can kind of have it on by default. Are there features that are in Ruby that you have to turn on that way or are there tweaks that you can make or flags you can give the VM that that also allow you to do more concurrency or better concurrency.
Yeah, that's a really interesting question.
I I don't have a I'm trying to think through if there's anything that like sticks out to me, you know that. I think again, like the nine thread thread scheduler is still kind of experimental, but I think it would become sort of that kind of thing, like I see it's serving a similar role to WYGI, where like you know once once why it's just a thing you can kind of like say like okay, I want to
turn this on and like things just get better. I think the AMIN scheduled thread scheduler could be that same kind of role for a server or for sidekick or something, because the overhead of those becomes lower and now you just kind of get like technically you could you can scale your server higher based on that. So that's that's probably the only one that comes to mind, but it's not really one that you can actually utilize on production today,
so it's not a good answer in that regard. Otherwise, I guess actually, probably the one that comes to mind that actually exists that you could tweak something or whatever to turn on to potentially get some benefit is probably reforking.
That's the only one I can really think of, and so Poom, both Poma and pitchfork have a capable for reforking, and reforking is something I haven't really dug into too much myself, but it just comes to mind as like a hey, like if you turn this on, if you take advantage of this, you can potentially have processes that take close to as you know, like near as much memory as like a thread would, but can actually run in parallel, so you kind of get like that that
ractor flavor without having to like change how you code everything. And so so yeah, reforking is probably the only thing I can think of that's like semi built in right now that you can take advantage of the certain things. And I'm curious to see if more tools end up picking up on the reforking concept. It's still technically I think experimental in Puma. It's obviously like the flag show future of Pitchfork, and that's what Shopify is using and
that I think saved them. It was like something it was like eleven or fifteen percent of like memory and latency or something like that.
I think it was. It was.
It was a There's an article that John Boucier posted about it because I was I was asking at one point, like how.
Is this doing?
And then a little bit later they had posted ale saying like pitchworks on prod.
Here's the benefits that we got out of it.
So that's probably the only thing I can think of today that you could take advantage of that figure not but I bet there are things out there, and I hope that there's more things I find as I dig into the series that I'm like, oh wow, like yeah, I can tweak this thing. I can tweak this like stack size or something like that. It's like you know when you're trying to scale and tune your your Ruby instance, you can take advantage of that.
Yeah.
Yeah, it's funny. I remember seeing the fallout from all of the Pitchfork stuff and it. It kind of like was a reflection of all the work they had done previously, like with copy on right and like objection right. Yeah, it's like a culmination of events that just like oh, hey, look we like shaved off this massive chunk of time.
Right, Like that's a great point that it really does.
It really has it all together and now all four lines appeared.
At one exactly. Yeah.
That's that's that's like the best way to describe it, because you're right, like earlier versions I seem to remember. I think it was like Ruby two or something like that. When it came out, it was like, oh, we've got like copy on wright, but they when they did a garbage collection to like marked every object, it was like, right, all the copy on right goes away. They've done all this work to improve that. Over time, it's easy to forget about that stuff because it's come so far.
But it isn't.
I mean, like you know, I do see like an incredible amount of work, like looking at the issue tracker and all that stuff that these people are doing. You watch like Ruby Kaygi talks and stuff where someone's like, like, was it Jeremy Evans.
I think he did a talk on.
Like it's like, oh, this particular thing I made it like a no up because you don't actually like use this particular object or like unless you do this other thing. And so it like saves like five megabytes of memories. Like all these small things just culminate together and we all just we all just benefit from it, which is awesome, not stuff you would think of as like a higher level programmer like I think we all are, which is like, oh, like I'm thinking about like how do I make these
like HTP requests better? And they're like how do I make how can I do a million iterations instead of right five hundred thousand? You're like, cool, that's great. I'm glad you thing about that. Yeah, yeah, I know.
It's it's the race to see, Okay, well our resource is cheap enough that we could just have like more resources or like like you know, does it really matter that we're making things more performant in the end, right, Like I don't really know, but I'm glad people are working on it.
Well, It's it's interesting you bring that up, because at scale, all the tiny things add up. But if you back it all the way off to hey, Chuck's running his stuff out of a garage and linode, right, yeah, you know, so you know, and then that's effectively what I'm doing. Right, I'm in my house and I run things from here
and you know, host on linod. So if if I can get more resources out of that server or maybe two servers or however, I have it set up before I have to scale or figure out some of this other stuff. I mean, it's it's not just down to hey, the server's more efficient, but it's also hey, I can get much further down the road before I have to add complexity and figure out how to do the ops to make this stuff come together.
So it benefits people on both ends, right, It's almost like it benefits people on both ends the most, and then in between it's kind of like varying levels. But yeah, when you're at that that lower end, we're like, I just really, I don't I want to spend like eight dollars a month on this thing. Like yeah, if you shave off fifteen megabytes of memory, it's like, oh, that actually did benefit me. Now I can like do this extra request or whatever. So that's a really good point.
Yeah, And then the other thing is is my scaling strategy is I'm going to buy bigger source.
Right sure?
Yeah, yeah, you know, and it's like live in that land and it's easy and it's cheap anyway.
I always like, you know, can I run it on a pie? You know, and like it's like the crux of like you know, they're so cheap and like you know, can you just install it and make it work there? Yeah? And like that's that's honestly a significant barrier because like it is a resource constraint like yeah, but but it does have like a very specific value that's very small. So like you know, I like that to be my I put my like you know, point of can I
get this to work here? And it makes me wonder like you know, but you know, if I had a Commodore sixty four lying around, like could I run anything on that? Like I don't know, sure, probably probably not much, you know, like right yeah.
Probably yeah, probably not most like higher level languages. I mean I'm not even sure. Maybe like an m ruby or something, because I know m ruby is like like targets like like my Coro controller type device yeah so yeah, embedded devices yeah, so maybe there. But yeah, it was
like an interesting talk. I think it maybe it's ruby, kaygi or something about they're using like m ruby like it was for like it was during COVID and they were doing it was to do like martial arts, like remotely or whatever.
I'm not sure if you guys. I think they use like.
M ruby to like control like the the smaller units, and then they used like j ruby to do like an android apt to like control how the thing responded to it. And yeah, so, but that's true, like a common arcy is before. Yeah, wo anything round there. I guess see probably would c probably can always run it everywhere, depending on how you write it. But I sort of promised myself my whole life, I would like most of my programming career, I'm like, I'm never gonna learn. See
that seems like why would I do that? And now I'm doing it because it's it is still just like if you want to get into little levels of languages or anything, it's it's still the one to use, and it's pretty It's not terribly hard to learn, but it is terribly hard to not destroy everything with by accident.
But yeah, so I'm curious, Like I know, we're like almost out of time here, but like I always wonder like, Okay, like if I have this thing like running on you know, a pie or something like this, like you think, okay, well I just buy another pie and I can replicate it the process and like spread over the machines, Like you know, how easy is that from like a concurrency perspective like within Ruby, Like is that like a forking or like not even a forking, but like there's is
there even like a shared like you know system library or built in way to do that kind of thing? Or am I kind of sll dependent on IBM or something that have a library that I have to use?
Yeah, I'm not sure I have the best answer there. I I've always liked the idea of like pies and and uh you know our do we know stuff like that, and I'll buy them and then I'll like I end up really doing very much with them and just feel sad about it. But uh, yeah, that's interesting. I think it probably would be like an m ruby type thing.
I would imagine, depending on I mean, some pies can actually have pretty okay hardware on them right to my understanding, Like they're not they're not super beefy, but they're certainly not like an rdino.
Is that is that to say?
Yeah, I think so, Yeah, yeah, I think you can run rails on a.
Yeah, so I think you probably could take advantage of all of the regular concurrency.
Like what I would what I would love is just to have like you know, k eights or like kubernetties, but like in a physical form, you know where I just I just add, right, that's a.
Super cool idea. Yeah, And I honestly like what comes to mind first for that sort of thing is probably like something like a SYNC type based you know, because it's fibers. They're a lot lower overhead, they take less memory, you know, they you know, on a on a pie, you probably don't have a lot of cores or any pores.
I'm not sure.
Well, I mean obviously have some coors, but I don't You're probably not much beyond like a double cores or something.
Yeah, exactly.
And so like having a couple of processes and then being able to use fibers to communicate between things, and yeah, that's kind of a cool idea of like you add another pie, it's just like another no develop on right, Yeah.
Yeah, I would so like to use d r B under the cover.
You probably could.
Yeah, if you run it to really like just like communicate it through like a more like RPC type interface. Yeah, communicating DRB through those would probably make the most sense rather than trying to do some other layer or whatever. So yeah, communicating DRB now, I really want to try DRB and fibers together actually, because I'm sure it's worse.
I bet, I bet that's and and if it's not a workable solution, I can't imagine it would take very much.
Yeah, and probably just because we've spoken about it into the air, Samuel Williams has probably hurt it somewhere, Like I sense a sense a fiber solution that that needs to be done. So if it doesn't work, probably, yeah, Like I it's like hardly I can ever go to like a random Ruby project and I'd be like Samuel Williams just supposed to think here.
It's like he's the dudes everywhere.
He's like, what is it like Andrew Kane or something the instacar made like five million gems, Like they're they're very like similar type people where I'm like, I don't know how you are involved in all these things and have like a family and all this stuff.
Right, that's great. But yeah, that's that.
That does sound like a pretty reasonable solution sort of because d RB uses like a it's like more like a binary protocol type thing, right, yeah, yeah, communicate between each other.
Yeah, yeah, I don't see why you couldn't sneak that up inside a fiber and then yeah, definitely inness communicate.
I thought it would.
It would just work, Yeah, it would probably, Yeah, I think it would. I would be surprised if it didn't because the mechanisms for how they communicate are probably all the level sockets and stuff like that that fibers support perfectly. So I'm looking forward to your your blog posts or your open source product up. We'll call it PA or something like that. It's like Pybernetti's or something.
That's right.
Yeah, I'm excited.
Valentino is going to have sky Net running in his house.
Right, He's just like you walk into a room and he's just covered in like raspberry pies or like what happened and like they.
I'll tell you what was with all this AI stuff? You know, I'm gonna make an AI clone of myself and then eventually just like have all the side projects work done, you know, right.
You're like, I always wanted to work and it's like, heyne.
Eight team, Yeah, go for it.
Right exactly. That sounds super fun. Actually I'm curious. Yeah, I mean, not the taking over our lives thing, but.
They the Pipernettes. We'll start like that, small big steps.
You know, Valentino will be the pie guy, the pie guy.
Yeah, all right, well we're devolving.
Let's jump into picks and.
Once you Yeah, it's fun. But the moment you get to Pypernetties, that's when you know you got right.
Yeah, somebody go to a bakery after this for sure.
Oh all right, Valentino, what are you picked?
Ah?
Sure, Yeah.
I've been working on a lot of fun AI stuff lately. I started this thing, uh where I'm trying to fine tune a l M specifically for Ruby co generation.
Uh.
And I started at Ruby Lang dot Ai and I'm I'm just almost wrapping up a library to go through the whole fine tuning process, just kind of for fun. All of this is just for fun. I hope something actually works from it, but yeah, you know, everything's Python generated, so we should have a Ruby you know, tuned version of that. And I got in touch with the hugging face. Uh, you know leaderboards and they have very specific evaluators. Somebody made a Ruby one, so I'm gonna try and use
the data for that. So yeah, so Ruby lang dot ai is something I'm working on a lot of fun and another way I tried, so we have like a Ruby Ai Builders discord if you're not familiar. It's so much fun. Just a bunch of Ruby people like playing with Ai stuff and sharing what we're learning. And I've
submitted this thing called the podcast Buddy. I just open source it and it basically just listens to your mic and uses whisper locally and transcribe stuff and then it like ongoingly just summarizes and you can interrupt it and ask it questions and it'll answer back like textas speech. There's a lot of fun I'm trying to get like other people like to help me start building it on because it's like kind of just stupid and fun and funny.
And so I come, come hack on it podcast buddy, code name VP podcast Buddy, And I'm gonna try and bring it on this podcast and have some fuff with it too, but we'll see.
A nice Yeah, it's it's interesting you talk about that, I'm gonna veer into my picks because what I want to do is I want to essentially build a podcast assistant, but it's more on the management and things like that, all the stuff that I'm doing to run the podcast.
So you know, let's say that JP couldn't come on at our regular time, and so I could just tell the assistant, Hey, find out when he's free, and find out when the other hosts are free, and let them get a scheduled right, and so then it does all the emails and coordination and you know, stuff like that, and finds the time.
Another one is if I get an email.
From JP and he's like, you know, when I was talking about that one thing, I didn't say it quite right, and I'd rather just drop it. I typically don't do that because it's a giant hassle. If it's if it's before we publish it, it's a lot less hassle, and
I'm more inclined to do it. But afterward I usually just tell people know, right, But it'd be interesting to be able to tell the assistant, Hey, go find where JP was talking about this thing and take it out and then have it, you know, work through the transcript, find the timestamp, you know, cut it out, all that stuff, and so yeah, yeah, this is where my mind has been lately, is, Hey, I do all this managerial stuff that I don't love, and you know, MICHAELA does a
lot of it, but I keep thinking that I could have her doing other things that are more not aud automatable, if that's a word, right, things that I can't have the AI do, or things that I can't easily have the AI do. And so, you know, when we were talking to Obie Fernandez and he was talking about having these assistants that do these different things, some of those were pieces of things that I'm looking at. You know, Hey, we have a new sponsor. You know, here's when it's
going to run. That kind of a thing. Though, I'm I'm also considering just not doing sponsors anymore, but that's that's a different conversation, you know, or at least just sponsor with my own products. But yeah, so so anyway, interesting interesting stuff. I usually do a board game pick as my first pick, so I'm going to veer into that really quickly. My wife and I went to the game store. Incidentally, our neighbors own the game store, so we're paying for their kids Christmas when we go there.
But anyway, we picked up an Unlock, and I'm not sure if people are familiar with Unlock, and I'm not sure that board game Geek actually has ratings.
For just unlocks in general.
It looks like they've got a couple of different versions.
Anyway, the Unlock Escape Adventures from twenty seventeen. That one has a board game weight of two point one zero. I'm guessing they're all probably pretty similar. Anyway, what it is is it's basically an escape room in a card game, and you have an app on your phone and so some of the things that you get from the cards you put the number from the card.
In and then you interact with the machine or.
Things like that. So we bought one.
The one that we bought, it has three adventures in it, and they're all based on different board games. So one's based on Ticket to Ride, one based on Mysterium, and the other was based on something else that I can't remember at the moment, but it's another board game that we played fairly frequently and so that was fun.
We did the Mysterium one.
We got stuck a couple of times, so it took us ninety minutes to do a sixty minute escape room, but honestly, about twenty minutes of us of it was we figured out. So in mysterium, you have a place, you have a person, and you have a murder weapon. And so in the unlock, you were doing the same thing. You were finding the place, the murder weapon and the and the culprit.
And so.
We found the location and we couldn't figure out what to do next, and what we needed to do was go.
Report it back to the the policeman.
So you know, otherwise it would have been seventy minutes for the eighty minute unlock.
But anyway, it was a lot of fun. We really enjoy them.
What I tend to find is that so she and I just did it together, they tend to be a little bit more fun with a few more people, So three or four people, we've done it with six or seven people, and that tends to get a little bit chaotic, and if you want to be involved in solving the puzzles, it just it gets a little bit hard. Sometimes it's like, you know, you have four people leaning over the same card and it just anyway.
But I really enjoy them they're a lot of fun.
We also have a Star Wars set of unlocks, and so what you do is you open up the unlock app and you just tell it which one you have and then you play through it. Anyway, they're really really fun, So I'm gonna go ahead and put that in as a pick. I had somebody complaint on JavaScript Jabber that I got long winded on my.
Picks, so I'm gonna just keep it short.
I've been watching the Olympic soccer. That's about the only part of the Olympics I'm interested in. My wife is watching like everything else except the Olympic soccer. But that's been fun, and so I'm gonna pick that, and then yeah, I'm this week or next week, I'm gonna have Ruby Geniuses and AI for Ruby dot com. Both of those domains will be up and you can join in the fun where we're doing weekly calls, get a newsletter that kind of a thing, so that you know, we can
kind of have these conversations in different ways. And then yeah, definitely go join the AI group on Discord because they're awesome.
All right, JP, what are your picks?
Yeah, I mean, I do want to say just the unlike sounds super fun. And I also have just always marveled that you always having a board game pick. You must have like a wing of your house that's just literally exclusively board games. I just I can't like place it in my brain, but.
I can't even imagine.
Yeah, but you can pretty much like, you know, fifty two ish weeks a year have a board game pick.
Just sometimes I duplicate them, but yeah.
Okay, yeah, yeah, I love board games when I hardly get around to playing them, but it's in trouble, So yeah, I've got I've got a couple of picks. So I was on Jason Sweat's Code Jason recently, and we were talking a lot about like smarts and how people like their mindset, how like how you can learn and things like that, and it reminded me that like, a very influential book for me is Mindset by Carol Dweck.
But yeah, super good. I always loved.
It pre kids, very influential for me with my kids as well, just trying to you know, embark in part that growth mindset versus a fixed mindset. So just a great book that I kind of commend to everybody.
The other one is like.
Being about to go on the podcast previously, I just started noticing everybody like how anybody sounds on a podcast and made me feel like I can't just use my AirPods. So hopefully this sounds pretty good. But I went out, I went to Best Buy and I got like a Wave three, so like not super expensive. It was like one hundred and forty bucks or something, and it's not crazy, you know, not like a five hundred dollars one or something, but I just wanted to have a better my quality.
And I use it for all my meetings and stuff now too, so I use it for other stuff as well. But I've been pretty happy with that, and it just I think it sounds a lot better than.
Just like some air pods or something, right, So I'm pretty happy to that.
And then the third one is just literally just the concept of going to a meetup. I've started so the Boston Boston's fairly nearby to me, it's about an hour drive, and I've their meetup started again and it's been great, Like I've just been meeting great Rubius the Boston Ruby group meetup I've gotten to meet like that's actually where I met Jason Sweat and Kevin Newton when they were doing some presentations, and just cool people in the Ruby community.
So I've been really happy that I've kind of been reconnecting with that and getting more involved. So so yeah, and then I guess I could pick my own blog series, but that seems a little self serving. But you can go to jpcamara dot com and read about concurrency. Uh so, yeah, those are those are my picks, two picks in a concept.
Awesome. Well, thanks for coming.
Yeah, thanks for having me. This is super fun.
All right, we'll wrap it up here. Till next time, Folks max out