2. Ruby, Regexes and Risk: Aaron Patterson Explains Why Hiring Open Source Developers Will Make Your Company Stronger

Jonan: It's a good name, isn't it?

Aaron: It's a very good name.

Jonan: Because it's code-ish. We're kinda talking about code.

Aaron: No, it's a Pokemon.

Jonan: Code[ish] is a Pokemon?

Aaron: I don't know if it is or not.

Jonan: Is it really?

Aaron: No.

Jonan: That would make it so cool. It sounds like a Pokemon.

Aaron: It sounds like a Pokemon. That's why I was laughing. I'm like this is the programming podcast for Pokemon people.

Jonan: We thought the name was very funny because it's a Pokemon, but also you should maybe tell people who you are.

Aaron: My name is Aaron Patterson. I am also known on the Internet as Tenderlove. That's my nickname. I work for a small startup company called GitHub.

Jonan: A recent acquisition of another small startup company.

Aaron: Startup company called Microsoft. You can tell they're small. It has micro in the name.

Jonan: Right in the name.

Aaron: I am on the Rails Core team, and I am also on the Ruby Core team.

Jonan: You were one of the first to be on both.

Aaron: I'm the only one still.

Jonan: Still the only one.

Aaron: Yeah, still.

Jonan: I brought you here today to talk about a lot of things, but mostly about Ruby and Rails because we have an advantage in having you here that you are on both of those teams, and very few people are. First of all, I want you to tell me a little bit about your background, how you got into this in the first place because you were not a Ruby ... You stumbled upon Ruby, and then you got involved in Ruby Core development. You wrote something else first. Tell us about your background.

Aaron: Well, I first discovered Ruby in, I want to say I think 2005, around 2005. I was working at another startup company that is I think dead now, classmates.com.

Jonan: Oh, no.

Aaron: I did. Yes.

Jonan: You worked for classmates.com. That's so awesome. Awesome. They're gone now, right? They're totally done?

Aaron: I don't know. If they're around, they're a former shell of themselves, I'm sure.

Jonan: Classmates.com, for some of the viewers of the Internet who joined later than us, what is classmates.com?

Aaron: Honestly, I would say that it was like the very first, probably one of the start of social networks, I think.

Jonan: It really was. It was supposed to be an online yearbook.

Aaron: Well, yes, it was an online yearbook. Basically you go online and you could see a list of all the people that you graduated with or any year really, and then you could email them. You could just email them. The way that they made money is they charged you to email your friends.

Jonan: To catch up with your old friends, or you could just lurk and silently judge all of your peers and compare your accomplishments. Always a healthy way to use social media.

Aaron: Yeah. While I was working there, I discovered ... I was a Java programmer at the time. I used to be a Perl programmer before that. I did not like being a Java programmer, and I kept thinking Perl six, this is going to destroy Java.

Jonan: Perl was going to destroy the world.

Aaron: Yes. I'd be like, I can go back to Perl. It will be amazing. A friend of mine was like, "You should check out this programming language, Ruby." I think I had friends who went to the No Fluff Just Stuff Conference, and they saw Dave Thomas give talks about Ruby, and they brought it back to the office and showed me. I was like, wow, this is amazing. This is what I've been waiting for.

Jonan: Was there anything about your Perl experience that made it more attractive to you early on? I know Ruby has a lot of similarities.

Aaron: Yeah. Using Ruby, I was like, "This is what I wish Perl was like." It had nice OO. It had the great OO features of Java and the ease of use of a scripting language like Perl but without all the crappy stuff from Perl. It still has some of the crappy stuff from Perl, but not as much.

Jonan: The majority of it. I never wrote Perl, but I do know of Perl that you can accomplish the same thing with different syntax in a way that you can make your Perl code intentionally incomprehensible if you aim to.

Aaron: Yeah, for sure.

Jonan: That's the thing that's actually hard to do in Ruby. You can definitely do it. People do Ruby golf. Ruby as a language, it encourages you. I'm going to say it almost forces you. It encourages you to write your code in a way that is human readable, and Perl necessarily didn't necessarily have that.

Aaron: I would say that is an accurate assessment, yes.

Jonan: Notwithstanding, you recognized some of the features from Perl in Ruby.

Aaron: Yes, for sure.

Jonan: You enjoyed those and so you stuck around.

Aaron: Yeah. For example, doing regular expressions in Ruby is very similar to doing it in Perl. As a web developer, 99% of your job is slinging text, making strings basically.

Jonan: That's what we're doing.

Aaron: That's all we're doing. Regular expressions is a really important tool to have in your toolbox. That was nice, especially compared to Java's regex support at the time. Honestly, I don't know what doing regex is like in Java these days, but back then in 2005, it was terrible, horrible.

Jonan: There were different ... I'm not well-versed in the world and depth of history that is regex. This stuff goes way ... There are different standards for how regex is operated. You can't expect your syntax to be applied generally.

Aaron: That's correct.

Jonan: Right now, in Ruby, we use a specific type of regex and we support this standard, right?

Aaron: Yes.

Jonan: In the case of ... It was not always there. Back when you were in Java, would a Java regex operate the same way in the Ruby world, one of those ones you had written a long time ago?

Aaron: No. Each language typically has its own regular expression engine. Ruby uses one called Oniguruma.

Jonan: Oniguruma.

Aaron: It's very similar, but it has different support than PCRE, which is the Perl regular expression engine. That one has very different support than POSIX regular expressions. If you use some tools like grep, you'll use by default POSIX regular expressions that are way more of a pain than PCRE, but you can usually use a switch to say like, "I want to use Perl style."

Jonan: In my Ruby code, what am I using, PCRE?

Aaron: No, you're using Oniguruma.

Jonan: I'm using Oniguruma specific.

Aaron: Yes, you're using it, but they stole all a lot of it from PCRE.

Jonan: It's not even that I could say Oniguruma is PCRE-compliant. They're distinct. There are things that Oniguruma can do that PCRE cannot do.

Aaron: Yeah, they're different.

Jonan: The portability of regex is not there necessarily, but for most things that people are doing, unless you're doing anything complex.

Aaron: Yeah, it's very similar. It's mostly the same. For some things like when you do a plus operator, that doesn't work in POSIX regexes. You have to do one character then the same character and a star.

Jonan: All of these differences add up to me not being able to take my regexes wherever I want.

Aaron: Yes. You're like, "Oh, I'd like to use sed one of these days." You tried and you're like, "This is garbage."

Jonan: I don't know how to do it. What am I doing?

Aaron: It's a table.

Jonan: It's very confusing and very opaque and difficult to learn about all the different syntax pieces. You were saying though that this is one of the examples of features of Ruby. How long was it after you discovered Ruby that you ended up getting involved with the Core development?

Aaron: I'm not 100% sure, but I was on the ... I think I got on to the Ruby Core team before I got onto the Rails Core team, even though I was a Rails developer.

Jonan: You started out as a Rails developer and you ended up being on the Ruby Core before you were on Rails Core.

Aaron: Yes, that's correct.

Jonan: You were already doing Rails shortly after you discovered Ruby. You jumped right into Rails or-

Aaron: Yeah. I learned about Ruby, and it was awesome, and then I saw DHH's weblog thingamajig.

Jonan: That famous video that was viral.

Aaron: The video thing. I was like, oh my, god, we would do all this stuff. Our web framework that we did use in Perl had many of the same features that Rails had. Our Java web framework had none of those features and a whole bunch of XML. I was like, oh my, god, I want to do Rails. I want to do it. Some friends of mine quit working at Classmates to start a startup, and they decide to do it in Rails, so I quit and went with them, and that's how I got my first Rails job.

Jonan: This was in a day when there were not many people working in Rails, right?

Aaron: No. I took a 30% pay cut to be a Rails developer.

Jonan: I think long term, maybe you could say that worked out for you.

Aaron: I think it did. It worked out. It was a good idea.

Jonan: You get involved with Rails development, eventually get involved with the Ruby Core stuff. Now that you're working at GitHub, you have been in position for a while at a couple of different companies where you are paid to be you, to contribute to the open source projects ostensibly that you have been working on. It often comes up where someone who has a lot of experience in open source, they're hired on by a company essentially as a sponsor of those technologies. There's a lot of value for GitHub in having someone who is Ruby Core and Rails Core inside the house.

Aaron: Yes, that is true.

Jonan: You have a lot more information about what things are going on in the community and where things are headed, and you can prepare your company for unexpected changes when you know, for example, that the next release of Rails is going to get rid of ActiveRecord. We're throwing it all away.

Aaron: We're throwing it away.

Jonan: We've decided this ORM layer is not the way to do it. We're going back to SQL.

Aaron: Heads up, everybody.

Jonan: Heads up, everybody. You can start writing all your SQL statements into your code again.

Aaron: Yeah. There's a lot of advantages. I know what's coming up in the language or in the framework. Not only that, but we can say ... In our case here where we wanted to throw away ActiveRecords, since I'm at GitHub and we use ActiveRecord, I can be like, "Hey, no, wait a minute, everybody. We actually use this. This is important to our business." Since I'm on the those core teams, actually, my voice matters.

Jonan: Right. They trust your judgment in someone who produces these.

Aaron: I think throwing away ActiveRecord might be a bad idea. Oh really? Oh, right.

Jonan: Well you're on the core team.

Aaron: We'll keep it.

Jonan: As part of this, then I guess what I'm asking is really the balance because I know that a lot of times, companies hire into these positions and then they're like, "Oh, we happen to have a very qualified Rubyist inside the house, someone who could debug a particularly gnarly memory leak error we've had with Rails for years and years. Why don't we stick Aaron to that problem also?" In addition to the regular work you're doing on Ruby and Rails, and is this a thing that happens at GitHub and how do you balance that?

Aaron: This is absolutely a thing at GitHub that happens. Of course whenever we have problems like that, I am more than happy ... I'm happy to help out with those. I love diving into interesting problems like that. Basically, what we do is I'm essentially the final line of attack. I don't think we have any hard and fast rules about it. It's just like an unsaid-

Jonan: Are you like support tier seven? There's the Aaron Patterson tier, basically the nuclear option. Two people have to turn a key at the same time so they can send you a ticket, huh? We're sending it up, click, click, click, click. Slack message. There goes your day. Your pager, it goes off.

Aaron: Yes. It's fine. Most of the time, people, they only ping me if it's something that's really, really hard to fix and they can't figure it out, but I don't mind helping with that stuff. I like helping with it, especially because typically, it turns out maybe it's a bug in Ruby or a bug in Rails, and I'm probably the most qualified person to fix it.

Jonan: You might have even written it. Those are fun.

Aaron: Yeah, that's a fun one. It's not bad. The balance is I don't do anything specifically to balance my time. Just I rely on my coworker's discretion to help-

Jonan: To help filter that out. You don't actually have to do any extra. They're respecting your time is what you're saying.

Aaron: Yeah, exactly.

Jonan: Obviously, GitHub is a very nice place to work. There are lots of brilliant people there. Many of the developers I know that I respect tremendously have ended up at GitHub over the years, but this balancing of the open source thing is a very common problem for people who end up in your position where someone is hired on to be almost like a sponsored position. I think there's this frequent discussion that comes up about charity and business or just more like every time I go to a manager and I'm like, "Hey, we should do a thing for open source." Not every time, but at times in my career, I've gone to a manager, and they've said things to me like, "Hey, this is a business, not a charity."

Jonan: My point to them is you are using Linux to run your servers and without the grace of the open source community, you'd be paying for SQL server licenses. How much is that compared to the salary of one developer to throw down on some open source and you get all the advantages that you reap from having someone dedicated to open source within your company? Including the huge network of professionals that you know in the industry. I think situations often come up for GitHub where they're putting together a third party integration with some company. They come to Heroku and they're like, "Hey, does anyone know anyone at Heroku?" Yeah, Aaron does. Aaron knows everybody in the community, right?

Aaron: Yeah.

Jonan: They end up being very well connected people, these people who are doing this open source work. I just wish that there was an easier way to ensure that you are going to be paid well for a long time to do this. Now that you're under this other Microsoft startup, I have faith that those checks are going to keep coming. Somehow I feel like that Microsoft company is going to make it through any potential tech bubbles, but it's a problem, right? The number of times where large numbers of open source contributors for major projects have been laid off by a company and it's seriously impacted those projects.

Aaron: For sure. I think one of the things that I do personally to help mitigate situations like that is make sure that I demonstrate my value to the company. I do it clearly through speaking to people, through my networks, things like that. Also, I spend time looking at the performance of our application. What are the devs at work actually trying to accomplish with Ruby and with Rails, and what are the shortcomings that the framework and language have? How can I, as a Rails Core developer, as a Ruby Core developer, what can I do to make the lives of my coworkers better? When I work on that type of stuff, it give wins to my coworker and then the whole business becomes more productive because of that. That's one of the things that I do to show, I don't know-

Jonan: Value.

Aaron: ... show value for what I do. I also like to do things like mentor people at work, help level them up, do that type of work as well.

Jonan: It's so fulfilling. This is one of my favorite parts about being a grown up software developer who sometimes knows a little bit more than someone else about something and I get to sit down and teach. I always end up learning more in that process.

Aaron: You learn more, and then when you can see that they're now more productive and everything is just getting better, you're like, wow, the entire situation has just improved and you're like, yes.

Jonan: Through direct effort of mine. It's a very gratifying experience.

Aaron: Yes, absolutely.

Jonan: Moving forward, do you think that you've seen a model that works to protect people in this position? What company have you seen that is doing this thing really well where they're like, all right, well here's ... You're talking about basically that communicating the work is as important as doing the work. You're talking about sharing, the value that you're presenting to your company regularly. That will help, but aside from GitHub, who obviously has no flaws, I think we can agree. Thank you, GitHub, for everything. You have no flaws.

Aaron: Yes.

Jonan: What kinds of mistakes have you seen companies make with regard to having a dedicated open source developer or what kind of things have you seen them do well?

Aaron: I think GitHub is doing particularly well. I would say, honestly, the crown jewel, best example would be RedHat. You can't really beat that, but that's also pretty difficult because they built their ... Their entire business model is on top of open source software. They got to do it. Honestly, Microsoft is doing really well with supporting open source developers.

Jonan: We're not just saying that because they pay your checks.

Aaron: That is correct.

Jonan: Actually, I would not have guessed even three years ago that Microsoft would have the respect that they have in developer communities today.

Aaron: I have to agree.

Jonan: It's really impressive what they've done.

Aaron: Yeah.

Aaron: Who else is doing well?

Aaron: Heroku.

Jonan: That one, Heroku Company. Oh yeah, I like those guys. They're great, yeah.

Aaron: I think they're doing well with this regard too. There are many different examples. I think the problem is it's just a pretty rare job. If you think of the number of developers there are in the world and the percentage of those developers that do open source, it's a very tiny, very small subset of the sea of developers out there. Having a job that is an open source job is probably going to be just as rare, basically the same ratio, same percentage.

Jonan: When you started getting involved with Ruby, people who really love Ruby a lot, they sometimes had towards paying Ruby Core developers at which point, they stop writing Ruby, which is sad because you get really excited about Ruby. You love this language so much. You want to help build it and then you're writing C. You wrote C before you got into Ruby.

Aaron: Yes, that is correct.

Jonan: Talk about maybe that process because that transition is really hard. I think we limit ourselves sometimes as a community because ... I'm not suggesting there's an easy solution of course, but I'm saying that most of the people who use Ruby don't necessarily have the C skills to get in there in the code and contribute to it. If it was all written in Ruby, for example, it has like has been dreamt up many times in the past. The project is to write Ruby in Ruby. What the advantage there is that all of the members of the community are able to contribute to the language itself. Talk about what it was like for you to start.

Aaron: It was hard at first, but basically ... Well, I don't know. I already had C programming experience before, so when I went looking at Ruby source code, I wasn't that intimidated by the C code. Actually, Ruby C code is pretty darn good. The thing is I think there's a difference between writing in Ruby and implementing a language. Just because you can write in Ruby, it doesn't mean you have the chops to write a language.

Jonan: That's true. It's a very different style of programming is what I think that you're ... I recently had opportunity to write a game for the first time and working within a game loop and learning all of the pitfalls that commonly come up in these worlds. It's a very different way to think about writing software. When you're writing and when you're actually implementing a language, it's a much different experience obviously than just using one.

Aaron: Of course, Ruby is way easier to use than C for sure. Some of the things, some of the virtual machine optimizations that Ruby uses require direct memory access, which is not something that you have necessarily in Ruby. Not only do you need to expose direct memory access in Ruby, but you also need to understand what the implications are of doing direct memory access. You're not just doing Ruby programming, you're also messing with the machine too. It would be nicer if more of Ruby Core was implemented in Ruby, but I understand why it's not.

Jonan: I think that it wouldn't be of that much value if it were.

Aaron: It would be easier to read. C syntax sucks. It's not good. It's not fun to read. It'd be a lot easier to read if it's in Ruby, but that doesn't necessarily make it easier to contribute to, I think.

Jonan: If I want to get started in Ruby, I am C developer. Maybe I got my degree and did my work in C for a school. Now I want to go today. In the next hour, you and I are going to sit down and pair on some issue. Where would I go to find those things?

Aaron: You can go to Ruby's Redmine and read through the issues there.

Jonan: Redmine is where Ruby keeps their issue tracker. I'll link that in the show notes.

Aaron: Bugs.ruby-lang.org. You can go through and read those. It is a website.

Jonan: If I find a bug on there and no one has commented on it and I'm like, this one is mine. I'm going to do it. I put my little comment on there. I may very well find out that someone is actually working on that probably because I didn't check the schedule of place where people are working on things. If I understand, there's a meeting in Tokyo where people get together and they talk about what features they're going to pick up that month.

Aaron: That is correct. Yes.

Jonan: Is it possible that someone would have already ... If all of the bugs are assigned already as they come in during the…

Aaron: No, no, no. They just come in and they're unassigned. If you find one that's unassigned-

Jonan: Safe bet that no one is working on it.

Aaron: Yeah.

Jonan: I could raise my hand up and say I'll take a crack at this.

Aaron: Yes, for sure.

Jonan: I write up my patch, and I'm working with SVN to get that up.

Aaron: Yeah, you don't have to. Ruby Core, our main repository is SVN, not Git, though we're in the process of changing it to Git. We have a mirror on GitHub, and you can just go clone the nearer-

Jonan: I could work there. This is actually I think the one time that I ever got to commit into Ruby, it was immediately ripped back out again because I broke it. I recently found out yesterday, so I wrote this with Aaron's help probably three years ago when I was at New Relic, I think, and I broke Windows with my commit, but I was so pleased with myself that I had a commit in Ruby. I was so proud. It's my proudest accomplishment. I see Aaron six months later, he was like, "Oh, you didn't see" ... You walked up to me. He's like, "I'm sorry about that commit." I was like, "What do you mean?" He's like, "Oh, you didn't see? We had to revert it."

Aaron: We had to revert it, yes.

Aaron: The revert is reverted so it's back.

Jonan: Yes, I'm back. I have a commit in Ruby. I'm so proud of myself. As far as workflow goes, when I did this, you can create a PR against the Git repo and then someone who has access to the SVN will take care of getting it in there for you.

Aaron: That's correct. Yeah. You can send ... Our workflow is different than just a straight up GitHub workflow, but you can send a PR and any Core team member that's like, yeah, that's good. They just basically manually merge it.

Jonan: They just manually merge it in there, and they'll put your name on it and everything. Somewhere there exists a thing that says Jonan in the history of Ruby.

Aaron: That is correct.

Jonan: I've done it folks. I finished this lifetime's work.

Aaron: You know what's cool though is your commit now ... When they ship out Ruby with Mac OS, now your commit is on all those machines.

Jonan: I'm on Macs.

Aaron: Yeah, totally.

Jonan: That's so cool.

Aaron: Isn't that cool?

Jonan: My name exists as text on new Macs. That's awesome. I'm pretty great. Good job, me. Let's talk about Ruby. I guess this is maybe ... We're going to change tacks here a little bit. I want to talk about what you would want in Ruby Core that you could just have magically right now. You don't have to as a team expend any effort to have a thing. What's the thing that you're like, man, I wish we already had that in Ruby Core, a feature, dream feature?

Aaron: That is a very easy question to answer. I would like a syntax for read-only data structures.

Jonan: A syntax for read-only data structures. I have a hash but nobody gets to write to it.

Aaron: Yeah, I would like that, and a way to say that a particular data structure is read-only but ... Basically similar to Freeze, the Freeze method, but Freeze method is recursive and goes deep because-

Jonan: Isn't there a deep Freeze or there was a deep Freeze?

Aaron: No, there's not. We might define that in Rails. It's not a Ruby thing. Right now, if you have a hash, you can freeze the hash, but the members of the hash are still mutable. I would like to be able to say like, no, this whole thing is ... Everything in here is read only. The whole thing is read only.

Jonan: The values, just to break this down a little bit, I have a hash and it has two keys in it, A and B, pointing to one and two. Even if I freeze this hash, the A and the B cannot be changed, but the value one stored at the A key can be changed. Is this what you're saying, when it doesn't freeze deep? Actually, for our deep freeze, we're talking more about the case where A has a hash itself. The value of A is not one. The value of A is a hash with C and D in it and three and four, and that hash can be changed.

Aaron: Yeah, exactly.

Jonan: Only the key part of this key value situation here is ... or rather, if the value ... The hash couldn't be swapped out for an array, for example, the top level. If I have frozen the hash, I have a hash that says A is empty hash. I freeze that hash. I couldn't then-

Aaron: You couldn't mutate the hash.

Jonan: ... say A equals array, but I could change ... I could add all sorts of things, key value pairs to that hash.

Aaron: No. You can't mutate the hash. If you said like hash.freeze, you cannot mutate the hash anymore. Let's say the hash had a key that's A, and then A pointed to an array. You could freeze the hash and that hash would be frozen. It's immutable. You can't add anything or delete anything from it, but the array that's inside of that hash, you can still mutate that and change it around.

Jonan: Add numbers around and-

Aaron: Yeah, do whatever you want.

Jonan: Freezing. When we talk about deep freeze, we're talking about freezing down through multiple layers.

Aaron: Through all of it, yes. In that case, it would be like, oh, the hash is frozen, but also the array inside of the hash that's also frozen. The whole thing is frozen.

Jonan: Your dream feature would be to just have a simple piece of syntactic sugar you could put it in a hash decleration that says this can't change.

Aaron: Yeah. I would like a thing that's like, okay, I'm going to declare a complex hash. It's got a hash with a bunch of keys and those key points to other hashes, and maybe those hashes point to other hashes.

Jonan: There might be a puppy in there somewhere, whatever you got.

Aaron: Yeah, exactly. I want to be able to say this whole thing, read only. I want to do that at runtime too. For example, you could change the JSON parser to say, okay, JSON parser, when you parse a hash, I want you to make sure that that hash is frozen. When you get it back out, nobody can mutate what came out of the JSON parser, for example.

Jonan: Which would be super valuable because then it makes it easier to find errors and bugs and things like that. These things that handling this JSON comes out of the parser, then you may be blaming the wrong part of your stack for a problem.

Aaron: Yup, exactly.

Jonan: What feature would you cut if you could throw something away?

Aaron: I would probably get rid of ... I'd get rid of a lot of the global variables, like the dollar magic variables, like dollar 1, dollar 2, those things. I'd get rid of those. I think a popular answer to this question is the flip flop operator, but I would not get rid of the flip flop operator. I like the flip flop operator.

Jonan: Did you use the flip flop operator?

Aaron: Every time I go to the beach.

Jonan: I walked right into it, and you set me up for it, and I could tell it was coming. There's this look you get in your eye, and I always know I'm walking in ... Yet, I do every time. This feature that you would take out would be all of the little bits that got left around. These dollar variable things.

Aaron: These are all Perl. Yeah, Perl-isms. Yeah, I would get rid of the dollar ones, dollar twos, those things.

Jonan: I wanted to ask you about the future of Ruby as a language. What do you think moving forward is the biggest barrier to Ruby adoption? It's possible in 20 years that we're talking about the extinction of Ruby, this thing people will always say Ruby is dead that they've said every year forever. Ruby is of course very much alive and killing it. Someday, it may come to pass that that is the case and maybe not, but what could we to grow Ruby adoption? What do you think is the biggest obstacle?

Aaron: It's weird because people say, oh, Ruby doesn't do say non-blocking I/O, but it does. Just the people who say that don't know how to do it. It's not easy. You can do it. It's just not easy. If we had easier ways to do that, but I really think the best ... Well, two things would help push it forward more. One is the [NJIT 00:30:08], getting the JIT, getting it so that it's actually fast. The other thing is better concurrency or better parallelism.

Jonan: The distinction between parallelism and concurrency is explained very well by someone I can't remember, but there's a presentation I have in my notes somewhere to go back to about this exact thing. I'll look it up for our viewers.

Aaron: Parallelism is running many things at the same time. Concurrency is switching back and forth between multiple things over time.

Jonan: It's just like process gets scheduled by the CPU. It's like, okay, A, you can go, and B, you can go, but A and B are not ever running at the same exact moment.

Aaron: The same exact time. No, not at all.

Jonan: A concurrent model, which is mostly what people do today, concurrent programming. Ruby is difficult to parallelize because of the global interpreter lock.

Aaron: Yeah. When you do parallel programming in Ruby, there are so many caveats to this. When you do parallel programming in Ruby, it's mostly concurrent basically.

Jonan: We've reached the end of our podcast here. Do you want to share anything else with our users far and wide?

Aaron: I don't know. I don't have anything to share.

Jonan: Give advice to new developers coming out into the Ruby community.

Aaron: Find something you like to do and do it.

Jonan: Find something you're passionate about.

Aaron: Yes.

Jonan: Yeah. I agree with you actually because I find nothing more interesting than talking to someone when they're excited about their topic and they're really passionate about what they're involved in, which is why I like to talk to you about Ruby and Rails because I can tell, after so many years, you're still very passionate about it.

Aaron: Yes, I'm very passionate about it. I love it.

Jonan: Thank you so much for joining us, Aaron.

Aaron: Thank you for having me.