Mining for gems in the Ruby and Rails ecosystems.
In this episode, we talk about Ruby and Rails with Richard Schneeman, principal engineer at Salesforce and Heroku Ruby language owner, and Penelope Phippen, staff software engineer at Stripe, and a director at Ruby Central.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Penelope Phippen (she/her) is a multifaceted Rubyist who works as a Director at Ruby Central, is the creator of Rubyfmt, and was formerly a lead maintainer of the RSpec project. She frequently writes and speaks about about complex aspects of the Ruby grammar, and issues of social justice for trans people in computer science. She's sad that she can't hug every cat.
Richard Schneeman created and maintains CodeTriage.com, a tool for helping people contribute to open-source When he isn't obsessively compulsively refactoring code he spends his time reminding his kids to wash their hands.
[00:00:01] PP: We have one very particular specialization, but the specialization we have is like the core use case for hundreds of thousands of businesses on the planet.
[00:00:23] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a Co-Founder of Forem. And today, we are talking about Ruby and Ruby on Rails with Richard Schneemann, Principal Engineer at Salesforce and Heroku Ruby Language Owner, and Penelope Phippen, staff software engineer at Stripe and director at Ruby Central. Thank you so much for being here.
[00:00:49] RS: Thanks for having us.
[00:00:50] PP: Hi.
[00:00:51] BH: So you've both been on some of our podcasts in the past. Penelope, you were on DevDiscuss, when I first launched, Season 1, Episode 1. And Richard, you were on DevNews, not too long ago. But just as a refresher for the audience, Penelope can start by giving us a bit about your developer background and what you do now.
[00:01:10] PP: Sure. Yeah. So my name is Penelope Phippen. I use she or they pronouns. I for a long time in the Ruby community was the maintainer of RSpec, the well-loved, sometimes hated testing framework by Ruby developers. As you mentioned, I'm a director at Ruby Central, where I work on organizing RubyConf and RailsConf, and was one of the program directors of RailsConf this year. So if you attended, you've got to see my face a lot at the beginning and end of each day. And I also maintain Ruby Format, a Ruby auto-formatter. Professionally, I work at Stripe where similarly I work on Ruby systems and in particular, I'm currently walking on a very large migration of Stripe's monolithic API.
[00:01:54] BH: And Richard, how about yourself?
[00:01:57] RS: My name is Richard. I've worked at Heroku for the last 10 years, Heroku/Salesforce/Heroku/Salesforce. Right now, I maintain the Ruby Buildpack, which if you've ever done Git Push Heroku Master, it does like bundle install and all that stuff flies through the screen, that's like me furiously typing at a keyboard actually, is how that works. Not true. It happens through a process called the Buildpacks. And so I maintain the one for Ruby as well as RDocs and all that jazz. I maintained Sprockets for a while. I partially maintained Puma. I helped Rails 5 get Puma in as a default web server. But yeah, I'm in top 50 contributors to Rails, but it's been, I don’t know, like probably a couple of years since I've had a commit there. And yeah, most recently I'm working on trying to get a gem for showing syntax errors called DeadEnd. I'm trying to get that into ruby. Right now I am working on a book for open-source. It's called How to Open Source. I don't have pre-orders open yet, but I do have a service that helps people get started in open source called CodeTriage. If you go to codetriage.com, you can sign up and then you'll get an email when the book comes out or my blog as well, I also have an email list there.
[00:03:09] BH: So how do you two sort of feel about Ruby and the ecosystem today? What's generally on your mind as you come in, like in the research and things like?
[00:03:20] PP: Sure. I guess like a thing I generally always say when I'm asked questions like this form of Ruby and particularly Rails is it remains the fastest way to go from zero to a functional application that can actually do something. I have yet to see, I know the language, I know the framework where you can move with the speed and efficiency that Rails gives you to get something out the door that is like a really powerful, functional, well-built, production ready application. The ecosystem has only got better for that over the past several years with Rails 6, doing lots of work to make it easier to develop on the front end. I would say if you just look at the sort of history from like Rails 3 to where we are today, everything's gone better. Right? And I don't think anyone could really say like, “It is harder for me to ship an application with Rails today than it was three years ago.” Frankly, Richard is extremely well-placed to talk about this, having basically built Heroku by hand for some of these things to enable the delivery of these applications to production. But the thing I so frequently like to remind people as Rails may no longer be the hottest technology in the world, but if you want to go real fast, it's a really good choice.
[00:04:35] RS: I completely agree. Can I just copy the whole answer, copy paste? Rails really shines and Ruby in general also shines organizationally. A lot of shops, especially when you're getting started, you don't know the shape of the product that it's going to be in. Penelope has been doing a lot of Rust. I've recently been writing some Rust and it's almost like the spiritual opposite of Ruby. It's like, “How safe can we possibly be?”
[00:05:02] PP: I mean, it's the amount of typing on the amount of typing, right? You have both like more characters that you have to input. And also, you have way more safety, right? It's actually very funny. In my side project I have at the moment, I actually have a Rails app at the core of it that's stitching all of these light components in Rust and Python together. I was like, “I need a work queue. Which work queuing system am I going to use?” Oh, Sidekiq obviously. Right? Sidekiq is like a really great example, I think, of something that is this in the Ruby ecosystem. I've never really seen anywhere else, just like this unbelievably high quality distributed job processing system. And the thing I think that is just generally true about the Rails ecosystem in particular is that basically any category of like software component you need, somebody has built an incredibly high quality component for you to use, right? Like OmniAuth, there are tools for generating super well-documented APIs. There are tools integrating with random cache servers and all kinds of third parties, like almost nobody delivers like a third party API today without a Ruby gem that comes alongside it like Twilio or, I mean, the company I work for Stripe, delivers an incredibly high quality Ruby gem.
[00:06:23] RS: Oh, that one.
[00:06:24] PP: So I think observationally, so many companies have reached success on Rails that now we have this powerful, vetted production ready path all the way up to a scale that most companies will never reach, right? Rails is good enough for GitHub to run it at the bleeding edge. Rails is good enough for Shopify to run it at the bleeding edge. Airbnb is on Rails, and just fundamentally, if you want to go from zero to something that is production ready and then continue to scale it for old time, Rails is an evident framework that we have seen that’d be possible in.
[00:07:02] RS: Yeah. You can also see one of the enduring things about the ecosystem is it tends to be extraction focused. Rails is almost like an extraction from DHH’s company. It's like, “Here are proven things we've needed in production.” And Ruby is so flexible. It makes making DSLs very easy and it makes making these components very easy and you can try out. And it's like, “Is this a good idea? Is this not a good idea?” And then later turn around and GitHub can say, “Oh, you know what? Everybody can use sharding. We're going to extract this awesome thing that we got and throw it into an upstream,” and it's like very in the ethos of Ruby and in Rails, I think.
[00:07:43] PP: One thing I think is really interesting is that GitHub basically rewrote the connection manager in Rails, like twice, I think. Eileen and John did a ton of work on that connection manager, not just for the initial extraction from GitHub, but then basically entirely rewrote it once it had become open source. So we kind of find that all of us can benefit from the work that these big companies are having to do, because they eventually get to integrate these very powerful systems back into the framework.
[00:08:16] BH: Yeah. I mean, that certainly resonates with the work we do. So our code base is called Forem, which is what we've called our company, which is the extraction of DEV, which is the website we built. Years ago, I chose DEV because I wanted to get some basic blogging up and running quickly, but with the opportunity to kind of build from there. And I'd been working on node in my day job at the time. That choice was sort of an impassioned rejection of node in my mind, even though I was still doing it day-to-day. But it was a little bit just like a good choice, and I think for the ease of getting going and the like, “Hey, let's not make this hard at the beginning,” it really worked well to help us get to where we are. I think on the decision to kind of later then pivot to like, “Hey, let's work to generalize some of this, make it open source.” The fact that it comes from the roots of being like that of extraction that sort of Richard started talking about, and the choices that that's enabled for us because we also share a lot of conceptual ideas with Shopify and there's a lot of GitHub crossover. It seems like we have a deep partnership with some of these other organizations contributing to the ecosystem that you can feel in some of the details and stuff like that. Does that feeling resonate when you two are taking part in development?
[00:09:42] RS: Well, one of the things that is coming up for me as you're talking is the Ruby ecosystem is also very focused. It's very focused around Rails. It's like, “Hey, we're going to go off the beaten path to Sinatra.” If you make an integration that works with Rails, it automatically works with hundreds of thousands of companies like, boom.
[00:10:00] PP: Yeah. And I want to say this is what we do in the Ruby community. Right? We have basically decided, like, “Ruby is going to be the best language for you to build web applications and web APIs in.” Right? I'm like, “That is a very conscious decision we've made.” But what that does mean is there are a lot of things that Ruby is not anywhere close to the best language for using, right? So if you need to build a really super high performance server that's doing loads of crazy IO, Ruby is not a good fit for you. If you need to do machine learning, Ruby is super not a good fit for you. Right? So I think when we talk about Ruby in the Rails ecosystem, we kind of need to acknowledge like we have one very particular specialization, but the specialization we have is the core use case for hundreds of thousands of businesses on the planet and we are uniquely well-placed to help you deliver that value quickly. I think a thing I am sort of notionally seeing that I was not seeing maybe 10 years ago is a lot of these shops now just sort of by forcing function polyglot. Right? So for example, at Stripe, we have a very large Ruby stack for our main API, but we also have things that are doing interchange that are a bad use case for Ruby that we have written in Java or Go. The other thing that I think is sort of really useful to understand is that while Ruby may be a great language for core products, it's not great for everything. The biggest change that I've seen in the last decade is people becoming more conscious of choosing to be polyglot as opposed to being like, “Let's write everything in Python,” or, “Let's write everything in Go. Well, let's write everything in Java.” Right? It's more like we're going to have this Ruby core and then we’re going to call out to like one of these other languages where it is better suited to do that job.
[00:11:55] RS: Over at Heroku, when I first started 10 years ago, it's like all Rails apps all the time. And then it's like, “Okay, we're going to get Java and then we're going to get PHP.” I don't think it even occurred to us that it's like, “Oh, you could have Java and Ruby on the same compute unit.”
[00:12:11] pp: Right.
[00:12:11] RS: Versus nowadays, it's kind of wild if you don’t and we're moving to all of these integrations. That actually caused us some issues with our magic and magic detection. It's like right now, even saying Ruby and saying Rails, all of them now also are node apps too out of the box.
[00:12:30] PP: Right. And I'm shipping Ruby inside Ruby format, which is actually mostly a Rust program. I literally compiled the Ruby interpreter into my Rust program. I have my Battlesnake, which is running on Ruby and Rust and Python. So one big change I've seen is that like the Ruby ecosystems tend to be super polyglot these days.
[00:13:13] BH: We're talking about the Rails ecosystem, the fact that it's an extraction from Basecamp, but up until this year, I think there was a lot of general community alignment with what was going on at Basecamp, like the way Rails followed DHH’s lead. If our listeners want to Google just what Basecamp has been up to in the last year, a lot of people left the company. You can kind of read into it. It's hard to kind of sum up in a sentence, but the DHH and Basecamp, their approval rating has dropped this year. Can we speak to how Rails will evolve or change or if they have had to gradually anyway? Can you two kind of speak to what is changing in terms of how decisions are made or how even RailsConf is going to be conducted if there's any sense of is it a change from like, “Hey, we're all following DHH’s lead”? Can we speak to that element of what's going on?
[00:14:21] RS: Yeah. When all of that came out, I was seeing a lot of people miss each other in communication. I was seeing the Rails core come out and putting out blog posts and being like, “Hey, this is what we're saying.” Then other people are like, “Wait.” There's a sense of everybody kind of thinks that Rails is governed and is running in a different way and it's not really super explicit. Like devoid of judgment, that's kind of how it is. I talked to some of the Rails core members about how are decisions made and talking to them like very much I see the day-to-day the face of Rails as being like Rafael. If you go on to the issue tracker, there's a 90% chance that Rafael's face is going to be like just merge something. And then there's also a lot of other involvement from a lot of other contributors. I think the kind of elephant in the room is, yeah, DHH still holds the trademark. All of the conversations still occurs in the Basecamp. I would be interested in having some conversations with some of the contributors about moving the invisible work to be visible and making the visible explicit and writing down some of these things. If there's a disagreement across people, how has it settled? Right now there's not an official formal process. I have not heard any sort of talk. Those are kind of all the things that are on my mind.
[00:15:48] PP: This is definitely a really interesting situation we find ourselves in. And I think I really strongly agree with some of the things Richard is saying around open governance, around having these procedures documented. I think this happens to open source projects that have grown up since Rails has grown up as an open source project. Right? So Kubernetes, Rust, some of these projects have very well-designed open source governance structures that I just think that wasn't prior on doing this when Rails came up. Right? And so I don't know that it's necessarily prima facie surprising that Rails’ governance structure is informal because I don't know that we, as an industry, knew how to do formal open source governance when that happened. And so I think personally for me, I would love to see what it would look like for the Rails core team to come up with a direction for Rails to move in a more governed way. Maybe not as formal as requiring people to post RFCs or really super detailed design docs, but begin to work out like, “How do we do that?” Right? Because right now, for example, Eileen can decide where pulling database management out of GitHub and just kind of do that because she's a core team member. But what if somebody from another large company who isn't contributing core to Rails has a good idea? There's no formal structure to start approaching that problem. So I sort of agree on potentially creating one there. In terms of RailsConf, we don't know exactly what we're going to do for RailsConf this year. It's more than six months out at this point. And so in terms of what will happen at the conferences, I don't know that Ruby Central has a clear position at this point.
[00:17:31] RS: I have seen more activity from DHH, just purely observational. He’s been more present, talking about all the changes to the front-end stuff and JS bundling and CSS bundling, trying to get rid of Webpack, got rid of Spring, which is like my…
[00:17:53] PP: Everyone's. Let's face it. Everyone is happy about Spring going away, I think.
[00:17:59] RS: Yeah. I need to blame. I turned it off on Heroku. That was one of my first feelings like, “You know what? I own this experience. I'm going to make a game time decision. I'm going to disable Spring for all Heroku customers.” It's like magically a source of support tickets disappeared overnight for basically no cost.
[00:18:19] BH: There's about as much maybe ambiguity as I have sort of expected when I asked the question.
[00:18:25] PP: I think if anything were to change, it would be on the members of the Rails core team to sort of resolve that ambiguity. And I think notably, neither Richard or I are members of the Rails core team. So I don't know that we can particularly say what will happen in the future. Right?
[00:18:44] BH: And with the primary maybe commercial stakeholders in this whole thing be Shopify and GitHub as the biggest influences or is that maybe just presumptive?
[00:18:55] PP: I think that's right. I think perhaps Shopify and GitHub are the largest commercial influences in Rails today because they have deliberately staffed teams with people who are committing on a regular basis, not to Shopify or GitHub’s code bases, but to Rails themselves. Right? So a big difference between GitHub and Shopify and say Airbnb where Airbnb is also a Rails app. I don't know anyone from Airbnb who's like showing up to the Ruby open source communities. I don't know anyone who's in those discussions. I don't know. I mean, I'm sure they have come to the conferences, but I don't know them personally. Right? My view on this is that Shopify and GitHub, it's kind of interesting. Some of this is that they've deliberately hired Rails contributors, but also they've grown them. Right? So we've seen new Rails contributors come up from GitHub and Shopify and that they worked with contributors who are already there, but have spent significant time working on open source. Right? So I don't know that there is an explicit sort of commercial relationship fab, but rather they are big Rails apps and they have people who are working actively on their frameworks. Right?
[00:20:14] RS: Yeah. And my take on it is at some point in time, they said, “Oh, hey! We've basically invested a lot of this.” They're betting big on Rails and they want a seat at the table, which is also good in terms of, “Hey, they're upstreaming that stuff. There’s staffing changes.” They're able to do that and move forward. In terms of contributors, those two just come up again and again. And I will also say, GitHub is kind of ebbed and flowed. At one point in time, GitHub had forked Rails entirely and was running on a forked version of Rails. It was kind of like this, “Whatever, this is ours. We've gotten all we can get out of these extractions and we need to make it our own.” I saw this also from some other companies also fork Rails. And then they're like, “Oh, we're going to start adding features.” And at some point in time, though, you end up with such a divergent product that you hire “Rails developers”. And it's like, “Oh, they don't know what's going on.” It's like, “Oh, we're frozen in Rails 3.2,” or whatever. You have to know this weird query syntax. It's like, “I just graduated from bootcamp. I don't know anything else.”
[00:21:20] PP: I remember very profoundly when I left DigitalOcean at the end of 2018, there were still Rails 3 apps around. And the reason they were around is because of the sheer volume of monkey patches. Right? It wasn't so much running a fork, just stuff was deeply coupled to Rails 3. And I mean three to four was a painful upgrade anyway, because of the params thing. Yeah. I mean, these companies did these internal forks and what they basically discovered is like, “We need to reconcile back to open source so that we can hire.” Right? And I mean, Eileen did an entire huge long talk about the GitHub Johnny from custom fork back to running cleanly on Rails…
[00:22:22] BH: Was there a time in Rails 2, 3, 4, and so on where things were the survival and the popularity of the framework was substantially lower than we're talking about today? We're coming at this from a sense of pride and stability in the ecosystem. When do you two feel that was most in jeopardy?
[00:22:46] PP: Probably the 2.3 to 3 upgrade. I mean, there are some wild stories from back in that day. That was around the time that like, “Yeah, I'm all deserialization vulnerability that allowed anyone to remote code execute against any Rails server on the internet.” And Steve Klabnik was SSH-ing into people's servers to deploy the patches for them because they didn't know how to do it. Steve literally sat in a corner at RubyConf deploying patches to people service for them. Right? And then the actual upgrade from 2.3 to 3 was obscenely painful. Going from 3 to 4 wasn't as bad. And also around that same time, we had the Ruby 1.8 to Ruby 1.9 transition, which was amongst other things, they introduced a completely separate Ruby. Most people don't really know this, but Ruby 1.8.7 to Ruby 1.9 was a massive upgrade because we got YARV. Right? And YARV, the Ruby interpreter we've used since then, was not super a hundred percent compatible with the previous Ruby version. Right? And so around that time, it was like multiple pieces of instability or crashing against you at the same time. Right? Ruby is also a lot smaller then. That was probably also when Ruby on Rails was hot. Right? That's when everyone was like, “Oh my God! You type Rails G some stuff and a whole web app appears in front of you.” Right? I mean, you have to remember that David gives that 15-minute blog demo. That sent a shock around the internet. That didn't just land in our community. That landed everywhere. And we have Bryan Cantrill speak at RailsConf this year. Bryan is not a Ruby developer. He works at a company that builds hardware and he spoke about how impressive it was to see that demo at that point in time. He called it one of the great pieces of software storytelling. I think at that time, Ruby had kind of the hype. But if it didn't, I don't know that we could have survived that transition. It was painful. Right? And I remember this feeling of optimism. I remember going to Ruby meetups and just everyone had like big smile on their face and we all thought it was really, really cool. It's interesting. I don't feel like we're having the same conversations that we were having back then. I feel like when not talking about how to design with objects as much. We’re not talking about how to do testing as much. At the time, there was this real movement in the Ruby community around this that I think is not there anymore. I think it's really interesting how much the culture has changed. But to come back to the original question, I'm sorry, I kind of went on a monologue there. We have had these big periods of instability in the framework, but I would say everything after four has just been smooth sailing. Right? Four is when Rails really kind of settled down, four to five was an easy transition, five to six, six to seven. These are all easy transitions, whereas that never used to be the case.
[00:25:53] RS: Yeah, my favorite’s Rails 5. That's when I was able to remove a lot of hacks out of the Heroku Buildpack. A lot of the features just integrated natively. And I mean, going back to the governance and stuff, it was I think I didn't even have to get anybody's permission to do. I was just able to go in and kind of talk with my own PRs, talk with my own two feet, talk with my, I don't know, this metaphor is strained. But in talking about the Rails 2 to Rails 3, it also reminds me of like, “Oh, Hey, Merb!” That was when Merb was integrated. In the whole Rails controversy, in my head, I had a flash, I had this idea. There's an alternate universe in which Merb won that contest, that conversation. But it's so weird because prior to that, Bundler was not a thing. When I started working at Gowalla, I think either they didn't use Bundler or it was just really new or it was maybe in the pre-1, 1.0 days. And there would be days at work where I would just literally spend the entire eight-hour day trying to figure out what the hell. It's like, “Oh, you're just requiring this gem? What version of it is it?” “I don't know. I'm going to go ask my coworkers. What path should it be on?” There's no consistency. Yeah, it's almost kind of this lockstep of, in my mind anyway, this lockstep of pain and then fixing, like pain and then stability. And I think one of the big things to Ruby's credit is it's able to move forward and it's able to not just get stuck in stagnate whenever it's feeling that pain. Likewise, though, seeing as many Rails apps as I do, speaking of old Rails apps, we have a ton of, and there's Rails LTS, there's a ton of people still running on old versions of Rails.
[00:27:39] PP: Right, but no one older than 3.
[00:27:42] RS: Rails LTS still supports Rails 2. I am probably going to be dropping support for Rails 2. I'm honestly considering dropping support for everything under Rails 5 and moving it to a separate build pack and being like, “Hey, you're just getting what you've got currently.” But I mean, I think this stability and upgrade story, coming from the perspective of, “I'm semi responsible for running millions of like apps,” I see these pains multiplied by a million times a million, I do wish actually had, as a value, conscientious upgrades, maybe. We've gotten better, but I still feel there's room for improvement.
[00:28:21] PP: I feel the upgrade part is way easier now than it used to be. Maybe to put this contrastively, right? I know lots of people who had 3 to 4 pain. I know relatively fewer people who had 4.2 to 5 pain. I know almost nobody who had 5 to 6 pain. Right? I mean, your sample size is bigger than mine, for certain, but the amount of pain is clearly going down over time. These upgrades are getting easier. The framework is getting more stable. The changes to these APIs are being done in a more incremental way. If you start a Rails app now, it's going to be way easier for you to move on to seven, to eight, to nine than it ever was in those early days to move from say three to four, to five.
[00:29:08] BH: So as is so often the case we've let Rails overshadow Ruby, I think a little bit as the conversation has gone on. So Penelope, I want to give you a chance to talk about the most interesting things you feel like you're doing or seeing in Ruby, through your work with Ruby format and Stripe and Ruby itself, regardless of Rails.
[00:29:31] PP: Things that are really interesting to me right now include compilers and JITs. So we now have seen a handful of JIT implementations in Ruby, both MJIT and then Shopify’s JIT, the name of which completely escapes me. Right?
[00:29:46] RS: I think it’s YJIT.
[00:29:47] PP: YJIT. Yeah. And then Stripe has released the Sorbet Compiler. We all sort of seeing these approaches to making CPU time bound Ruby faster, which take all sorts of varied approaches. And I think this is really interesting because one of the things that has always bound the Ruby language is how efficient it can be on CPU time and machine density. Right? And if you can JIT or compile away that problem, then Ruby becomes a much more compelling language for really, really large distributed systems. The other thing I will say though is that whenever we talk about this, I think it's always important to remember that Ruby is an incredibly fast interpreted language. Ruby is as fast or faster than Python in nearly every CPU-bound benchmark without JIT. Right? And the reason for that is that just all of the non-JIT or compiler performance work that has gone into the language over the last decades, since Matz announced Ruby 3 would be three times faster. But yeah, I think the compiler and JIT stuff is really interesting right now.
[00:30:58] RS: Speaking of it as a scripting language, when you go and talk to Japanese developers and you go and talk to Matz, they do believe that it is more general purpose. They would never say like, “Okay, we can make it a thousand times faster, but it'll have a ten-second boot up time because then you can never use it for scripting.” And scripting is a core thing that they want to support.
[00:31:15] PP: To that point, I mean, in Japan, they have Ruby in cars, they have Ruby in satellites. At the RubyKaigi in Fukuoka, the Fukuoka government sponsored a conference. That's equivalent to a state, roughly speaking, in US terms. The local state basically sponsored the conference because they have determined that the Ruby programming language was of such significance to their industry that they wanted to be part of it. And the governor of Fukuoka Prefecture came to give a speech at the conference about the importance of the Ruby programming language to their local economy. And a thing that I sort of found really interesting on that point is that Ruby is used totally differently in Japan. It powers embedded. It powers industrial systems. It powers all sorts of things that we would never think to use it for over here. I have no idea why, but I think it's fascinating.
[00:32:13] RS: I am actually very excited by the error highlight gem into Ruby 3.1. it is kind of showing, “Hey, we're valuing more…” they've always valued developer ergonomics, but they're valuing it more and it's having come from recently just doing a little bit of Rust, seeing a little bit of the ergonomics around errors and exceptions and just more human readable, which also gives me hope and faith with the gem that I'm working on with DeadEnd. The other thing that's really exciting for me is Ractors. They don't work super well. It's very experimental. They don't work super well with the rest of the Ruby ecosystem. They can cause a segfault pretty easy. But just in terms of being able to unlock and use multiple cores, once it's a little bit more baked, it opens up areas for Ruby to be a lot better in say then like, yes, Python, you can do NumPy, you can do like the matrix stuff, which is hyper optimized, but you're still restricted to one global interpreter lock inside of Python. And so I think that is a really kind of exciting area to see explored.
[00:33:19] BH: Well, this was a lot of fun. Thank you both for joining us.
[00:33:23] RS: Yeah. Thank you for having me.
[00:33:24] PP: Yeah, of course.
[00:33:34] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.