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