The Relicans

Cover image for Living in Ruby-Land and Rebuilding Rails with Noah Gibbs

Living in Ruby-Land and Rebuilding Rails with Noah Gibbs

mandymoore profile image Mandy Moore ・33 min read

Kirk Haines interviews writer and teacher on Software Development Noah Gibbs about sharing his code with people by writing a book: Rebuilding Rails, a book about understanding Ruby web frameworks by building your own, structured like Rails.

Should you find a burning need to share your thoughts or rants about the show, please spray them at While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

play pause Polyglot

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on Thank you so much for joining us. Enjoy the show.

Kirk Haines: Hi and welcome to Polyglot. My name is Kirk Haines, and you can find me on Twitter @wyhaines. And today, I'd like to welcome my guest, Noah Gibbs. Noah, welcome to the show. Do you want to introduce yourself to everybody and let everybody know a little bit about you?

Noah Gibbs: Sure. My name is Noah Gibbs. You can find me on Twitter as @codefolio. And I use that domain name in a bunch of places. I wrote a book called Rebuilding Rails. I've done some work on the Ruby language. But my understanding is I'm mostly here as a programmer that's been doing this a long time for Polyglot. I've done Ruby. I've done a lot of other things. You can't avoid it if you've been programming for a while.

Kirk: Yep. And we can talk about specific Ruby stuff if you want. I've been doing Ruby since 2001. So the floor is open, and we can talk about whatever you want to talk about. But why don't we kick this off with a little bit of information about where you started from in your voyage to where you are now and maybe where you started from and how you got involved with Ruby?

Noah: Well, getting involved with programming is a much older story than getting involved with Ruby. I was a systems programmer for quite a while, doing C on operating systems, device drivers, the low-level stuff. I worked at Palm, among other things, embedded different similar C sort of stuff. And I think I got into Ruby and Ruby on Rails the way a lot of people did, by which I mean I realized I was going to have trouble sharing what I did with anybody. I got to the point where I wanted to write a program I could share with somebody else. And I had that distaste that a lot of classically trained systems programmers have for everything other than systems programming. And so I'd seen the web, and then I'd go and look how you programmed the web, but I would make that face that classically trained systems programmers make when they look at PHP code, and I would give up in disgust.

And I sat down after a lot of time doing this, and I thought about what I'd want to do to be able to share the code I was writing with people. And I'd written installers in Windows, and Linux, and Mac, which all have to be done separately. And it's a terrible way to share code; writing in C and sharing it's terrible. And I realized after I had spec'd what I actually wanted to use that I'd spec'd a web browser. And so I went back and sighed deeply and looked back at web programming again. And this time, I found the 15-minute blog tutorial for Ruby on Rails. This was Rails 1.2. It was around that time. I'd seen Ruby before, and it looked like a better Perl, but I hadn't looked at Rails before. It was a good, better Perl. I liked Perl. But I looked at the tutorial, and I thought, wow, you just write what actually does something. You don't write anything that doesn't do things specific to the task. That smacked me on the forehead. I'd never seen anything like that. I was used to programming in C, and you get your trousers on in the morning that's 10,000 lines in C. [laughter]

Kirk: Yep.

Noah: And so I looked at it, and I saw it, and I thought I'm going to have to learn JavaScript and SQL and stuff now. And so for the next two years of spare time -- I still had a day job in C. I was architecting an operating system nobody ever saw. It's a shame; the demos were incredible. I spent two years teaching myself enough JavaScript to really count because I'd barely learned any of it and the basics of HTML and CSS. And I'd managed to almost completely avoid SQL up to that point. So that was from the ground up. And I was in the Bay Area. So I was surrounded by Ruby meetups and Ruby programmers. After I'd been doing this for a while, I specifically avoided all of those because I was terrified. Having spent all of this time just trying to speed run JavaScript, and CSS, and HTML, and SQL, and Ruby on the Rails stuff all at the same time, the idea that there were people out there who could just do all of these things and you could have a whole room full of them all at once I was terrified to get into that room. [laughs] So two years later, when I had been doing this for a long time, at some point I finally put on my big-boy trousers and went to a meetup, and it turned out, as you all know, of course, that they're ordinary mortal human beings. And I was pretty impressive at most of those topics by the time I was willing to talk to them because I'd been driven so hard by just being terrified of the whole thing. [laughs] I'd been a programmer a long time at that point, so I was reasonably good at absorbing this stuff. Not perfect, but not bad.

Around about this time, we'd finished having this operating system I was bragging about earlier. It became clear that it was never going to be anything by which I mean we had these gorgeous demos, and we were at the point where the company I was working for was going to have to sell it to a cellular carrier because that was how you sold cellular operating systems at the time. And this was just before the iPhone. So it turned out we were deader than we realized. But if the iPhone hadn't come along, we were still pretty dead. It wasn't going to happen. We weren't going to successfully sell it to a big cellular carrier. We were competing with companies that have to deal with it whether they want to or not. And it turns out turning us down was easy by comparison.

So at that point, I'd been doing Ruby long enough, and I was enjoying it enough that I thought I'd like to do this for a living. And so I went to my wife, and I had one of the harder conversations of our marriage where I explained that I'd like to switch industries now. "There's this other thing I think is more fun." And related to that, I spent, I don't know, ten months or so on a job hunt desperately going to a little Ruby company after Ruby company and trying a sales pitch that goes, "I've been a programmer professionally going on 15 years now and I'm expensive and kind of curmudgeonly and I've never done anything in your area. Hire me."

Kirk: [laughs]

Noah: It leaves a little something to be desired as sales pitches go. But eventually, I got somebody who was willing to give me a try, that was nice. It was a company that had taken an ancient Java app that had been the first app that this guy had written originally as an undergrad at Stanford. And he was now the chief engineer. It was this crufty organically-grown Java app that they were going to then spread a layer of JRuby on Rails across the top of. And having done this and successfully, they had successfully spread a layer of JRuby on Rails across some of it. They wanted a Ruby guy for that. I was an interesting choice for that role, but I did well on their coding interviews. So they brought me on board. Thus was I the Ruby guru at my first ever Ruby job, a pattern that oddly continued through all of my other Ruby jobs. It was a little weird when it wasn't a lot weird. [chuckles] I did okay at that. And I've worked in Ruby since then. What has it been? Somewhere north of 10 years. Every so often, I go back to LinkedIn, and I do the math, and I'm going to feel depressed and old. [chuckles]

Kirk: Yeah. It's hard sometimes to think of exactly when those dates were in time. Your comment about Perl and Ruby being a better Perl was actually my first introduction to Ruby around 2001-ish. I was reading a Perl magazine that had an article about this language, Ruby. It was in the Perl magazine. And I read through it, and I thought, wow, this looks like a better Perl than Perl, and so I went and I downloaded it. It was Ruby 1.6.6 or 1.6.7 at the time. And I downloaded it, and I took a whole bunch of my Perl code (because I was making a living as a Perl developer at the time), and I translated a whole bunch of snippets of that code to Ruby. And then I sat there, and I would sit at my desk, and I would compare them side by side. And after going through that exercise, I thought, you know what? I want to make my living in this language because it's shorter, it's easier to read, and it's more pleasant to write. And so yeah, it was a better Perl than Perl. That was my exact thought process.

Noah: It's really interesting. Ruby and Python are both nearly as old as Perl and are both, in their own ways, clearly reactions to Perl. And what I tend to say is the difference is that the Ruby people liked Perl.

Kirk: [laughs] That's true. I loved Perl.

Noah: Well, if you hated Perl, there's a pretty good chance that a lot of what Ruby took from it you don't like either. Both Python and Ruby are more structured and cleaner than Perl. But Ruby is more structured and cleaner than Perl in a very Perl way.

Kirk: Yes, absolutely. It drew a lot of inspiration from Perl, especially if you go and look at the old Ruby code. You go back to the Ruby code that was written in 2000, 2001, 2002, and it looks nothing like how Ruby is written today, nothing like it at all. It's fascinating. And yet it's still, in most cases, that code that was written in 2001 will still run on Ruby 3.0 or very close to it. Sometimes there are some little things you have to change but very close to it.

Noah: I converted a lot of Ruby 1.8 code to 1.9. And I'll say the biggest thing, the thing that bit us the most in different places and was the hardest, is the fact that hash tables these days iterate in insertion order, and they used to iterate alphabetically. That was the thing we had to change in most scripts, and it was a giant pain and a surprising number of them.

Kirk: I never thought about that particular change, but yeah.

Noah: I had never thought about that change, and then I got to port a lot of scripts from 1.8 into 1.9, and then suddenly I thought a lot about it. [laughter]

Kirk: Well, it's funny. I maintained 1.8.6 for the last; I don't know, two or three years of its life. Actually, I maintained it past the end of its life because I worked at Engine Yard at the time, and we had thousands of instances where they were still running 1.8.6. So I maintained it quietly and silently for a while afterward. But in my own code, when I would port it from 1.8 to 1.9, that insertion order for the hashes never once came up as a problem.

Noah: Huh. That's interesting. These weren't scripts I had originally written. I got to a company called Ooyola, and the first thing I did was to port a load of their code, but it bit us all over the place. I do remember working in 1.8 more recently than that, but not in an actually backported any bug fixes way, just in an old code sitting there sort of way. I got to the job after Ooyola years later, and they still had 1.8.5 sitting around in a bunch of places because that's what their Ops department had written a lot of stuff originally in.

Kirk: So, what brought you from that point to writing your book?

Noah: So I said that I'd wanted to share my code with people. The thing about being a systems programmer is you can't do very much on your own. The corollary of it takes 10,000 lines to put your trousers on in the morning in C is the sole C practitioner who gets non-trivial projects done on his own is a rare fellow indeed. There are just not that many. It's a hard way to do it. There's a lot of stuff you don't want to write in C, and people don't for a lot of that. And the book came with the idea that I wanted to get my code in front of people because I started trying to do that, and I realized I didn't have much clue how to do it. And I wound up taking Amy Hoy's class 30x500. I don't know if you're familiar with it. It's a product design class. It's one of the old ones, and it's still a very good one. I would say if you are a person who has never sold a product and you would like to switch from being a person who has never sold a product to a person who has built a product themselves and sold it at least once, I don't know any better way than 30x500 to make that transition. There are, of course, a lot of places that'll try to tell you how to do it. And they've all got dismal completion rates; even 30x500, which is a very good class, still has a dismal completion rate because it's an online class, and most of them do. But if you are serious about making that transition, it's a good way to do it.

Kirk: Interesting.

Noah: And so I wrote the book as part of that. Rebuilding Rails is my book. And these days, there's a video class with it and stuff. You can buy it in a couple of different packages, yadda yadda, yadda. But the orientation toward doing things for people instead of doing things on your own was a big part of that and in a lot of places in my life. And switching off C was part of that same thing because then I could build a thing, and then I could show it to people. I worked on a number of projects that I'd write the code, and it would go through the slow process of release over the course of years, and it would never get released. In a lot of cases, the code died before it ever got out the door in any useful way. I shipped device drivers for cable TV set-top boxes that never got turned into cable TV set-top boxes. And I wrote that operating system that we put a lot of work into that never shipped on an actual cell phone that a human being could buy. And there are a lot of stories like that; systems programming, especially for hardware, is full of those stories. And so Rails the idea that I could write a thing -- First I'd write a thing, and then I'd put it up somewhere that I could see it a week later, which was already not night and day, like a week later. And I know to a modern Rails programmer the idea that this systems programmer built a thing and he deployed it only a week later sounds pretty odd. But it was a big deal to me at the time.

Kirk: [laughs] I understand. I understand fully.

Noah: But coming from C, it's hard to explain to people, but C is a language where if you don't do a thing, it doesn't happen. And it's hard to even explain what I mean by that. Yeah, you're nodding.

Kirk: Yeah.

Noah: It's hard to even explain what I mean by that. So a modern garbage collected language is constantly doing stuff underneath you; it has to. You've got a garbage collector, and it's certainly doing things when it's run. But almost all of that has to happen in a background thread, which means there has to be a background thread, which means there has to be a thing you're not doing that's happening that you don't think of yourself as having told it to do. C is a language that is so gorgeously close to the instruction model that if you call a function, there's really only one function it can call. There's not even a set of methods to choose between. There's not a choosing process you don't see. You told it that exact function, and that exact function is what it's called. And if you don't tell it to call it, it doesn't call it. It doesn't do operator overloading. It doesn't do method dispatch. It doesn't do any of these cute, fancy, modern things. If you don't tell it to do a thing, that thing does not happen, which is, in some cases, a really good feeling. It's a terrible way to get work done, but it's a very good feeling to actually know what's going on.

Kirk: [laughs]

Noah: Rebuilding Rails came entirely out of my distrust for this new world in which things usefully happened, but I hadn't told them to. The idea that Rails is highly magical and so what I really needed to do was build something Rails-shaped from the ground up out of Ruby code while at the same time digging pretty deep into Ruby to figure out what was going on underneath it. And at this point, I'm pretty comfortable with it. I've worked on the core Ruby language; I wrote the book. I've done a bunch of stuff, including some pretty deep digging into Ruby. I flatter myself that I'm one of the more competent people in Ruby internals out there. And I have at least some things I can point out to, to claim that's true. But yeah, Rebuilding Rails is fundamentally about distrusting a thing you can't build.

Kirk: One of the interesting things that I'm getting from this conversation when we're talking about being a polyglot is how all of your experience as primarily a C programmer shaped your entire approach to Ruby and to Rails sounds like through the entire course of your experience with them.

Noah: Like with Ruby and Python versus Perl, it absolutely shaped what my choices were, and there were a lot of places where I could have gone very different directions, and I picked -- I'll tell you the other people from my background that I talked to took a very different set of choices at those places where it goes to very different directions. So it absolutely did shape it. It showed what those choices were, and at the same time, other people from the same background often make a very different set of them.

Kirk: Well, first of all, these days, do you find yourself just in your day-to-day working more with Rails or more with Ruby? Where is your focus? Where is your attention at today?

Noah: So I do a wide variety of stuff today. When I last had a regular full-time job which ended in 2019, I was working on the core Ruby language. I was AppFolio's Ruby fellow. You could think of me as the performance-oriented data scientist for the core Ruby language. And so I did a lot of speed testing things, timing things, tweaking things, and graphing the results. I have been working on my book and contracting and other multiple small mini jobs at once. [laughter]

You asked if I'm more Ruby on Rails oriented, both. And I find that the deeper I look under the hood in Rails, the less I make a distinction there. A lot of the problems I see people having with Rails -- This is an oversimplification, but everything is really about being too much in the Rails world and not necessarily understanding the things around it, for instance, the valid criticisms that I see about how this Rails model literally allows you to throw things together quickly. It doesn't scale up to a vast size team or a number of controllers. First off, no, it doesn't. That is 100% true. Second off, the idea that your framework should also model your entire code architecture is charming in languages that use a lot more lines of code in an application. It was understood that that was a very bad idea a long time ago. If you use a language like Java or C++ or something else that uses a lot of lines of code routinely very much, you very quickly hit this idea that it's cool that your web server has an API and all. But if that shapes the entire interface of your application, you did something wrong. Rails is very good, I think, API to the webserver. And when you have a problem like I want to run this service that doesn't want to run like a web server, great. You extract that service from your web server, and you have to have them talk to each other like, that's cool, no problem. And some Rails people are probably saying, "Oh, he means Service Objects." No, you attach a socket. You put this in a separate process and potentially on a separate computer. If you want it not to run like a web server, the first thing you do is take it out of your web server.

Kirk: Yup.

Noah: In Ruby land, that's treated as an extreme view; the idea that you should have multiple things and pull them out is an extreme view. And I think part of what happened is that I lived in C and C++ land for a long time, and I'm used to dealing with a lot of Ops people, and people who worked in C. And Java was gaining popularity in the world in the meantime. And in Java, there's a strong cultural norm that everything winds up in one bucket. Java has gigantic apps that do everything, and you may perfectly reasonably deploy a whole bunch of them that function in different ways but use the same codebase. You deploy five of the same bucket. And if one of them happens to be acting like your front-end server, and one of them happens to be a service in the back, that's fine; both of them do both.

Kirk: Yeah. I'm familiar with that. Ruby 3.0 introduced quite a few if you think about when you went from Ruby 1.8 to 1.9 to 2.0, there were some fundamental changes between 1.8 and 2.0 as far as how the underlying system worked and things like that. But there weren't, other than the few things like the hash insertion order and stuff like that; there weren't any really earthshaking language changes. There were nice things, but the evolution from 2.0 to 3.0 has seen a lot of changes.

Noah: I would have argued the opposite of that. I feel like 1.8 to 1.9 was a much bigger change than 1.9 to 3.0.

Kirk: Hmm.

Noah: Part of the reason I say that is that a lot of the internal changes, which should be completely invisible between 1.8 and 1.9, were massive.

Kirk: Yeah, the internal changes were absolutely huge, yes. But the actual developer experience, I don't think, changed tremendously.

Noah: But you feel it did from between 1.9 and 3.0?

Kirk: So what I'm getting at if you're using 2.7, you can go to 3.0, and your world's not going to change at all. But there are things in 3.0 now with regard to the Reactor model as well as the built-in concurrency fiber models that will, I think, propel a lot of evolution going forwards. So the evolution from these new things that you aren't going to notice, if you weren't using them before, you're not going to notice them from 2.7 to 3.0. No big deal. But the evolution going forwards, I think, is going to be significant because of some of these things that are available and even just the Git, the Git is still considered experimental, but the Git experienced a lot of growth between 2.7 and 3.0. And so I guess what I'm getting at is that there's a whole bunch of things that exist in Ruby 3.0 now that didn't exist before that have the potential to drive a huge shift. And I'm wondering where you speculate that shift is going to go how you see these changes.

Noah: So there's a specific change that Ruby has been trying to make for a long time, and the random programmers using Ruby have never gone for it. I'm going to call that the EventMachine transition. And a lot of the things in 3.0 that are new are that same general shape; the Reactor model, the auto fibers have very similar properties in terms of the benefits, in terms of the speed ups, and in terms of the sacrifices to the transition to EventMachine. Now, to be fair, EventMachine had some things going against it. EventMachine was a very imperfect choice in a lot of ways, having used it. It's not an enjoyable programming experience in all sorts of ways.

Kirk: I was a contributor on EventMachine, so I know full well what you're talking about.

Noah: I don't know how much better they could have done with that model, but I can see why that model was hard. Like, it was a hard sell.

Kirk: Yep.

Noah: And so it's a really interesting question whether Reactors or async fibers are going to be able to push that transition. There have been some neat models in Ruby before the old Seaside framework, which worked off continuations, which was a curiosity when it existed and doesn't work anymore at this point. And you couldn't really build it again on modern Ruby. It was still a fun idea. And you could actually build almost exactly that on modern Ruby if you did it out of fibers instead of continuations.

Kirk: I did. Avi Bryant, before he wrote Seaside, he prototyped it in Ruby and called it IOWA. And he abandoned IOWA when he moved to Seaside. And that was about when I was in the stage of I'm ready to build web stuff with Ruby. What is there to build? What is there to build stuff? And the answer was there was nothing; it was a wasteland. But I found IOWA, and IOWA was really, really cool. IOWA couldn't be used for a production app the way it was built, but it was really, really cool. And so I took it, and I hacked on it until I could use it in production apps. And literally, for 20 years, there have been production IOWA apps in the world. And I was terrible at the whole science of marketing what I had done. And so there are never more than a handful of other people building stuff. But yeah, we had something that looked a lot like Seaside with some compromises for pragmatism running all kinds of web apps all over the world.

Noah: So the biggest thing about Ruby 3.0 that I see as an advantage doesn't have a previous equivalent. A new advantage in Ruby 3.0 is that both fibers and Reactors have dedicated vigorous representatives on the core team, and that's a big deal. Koichi, of course, is on Reactors. Like, that's a big deal. And then Samuel Williams for the fiber stuff. And on the one hand, Koichi obviously is prominent in a way literally nobody other than Matz is and is probably the most active person you could have pushing a thing. But Reactors is also a much harder task than asynchronous fiber is. Fiber stuff is basically there. You could use it today. If you were saying, oh, I want to build a thing on fibers. You're not waiting for anything. It's just it's time to build it; it's there. It's released like today's a great day to start. And Reactors are not in that condition yet, frankly. Koichi is working on them, and that's a good sign. And I think they will be in there at some point, but today they're not.

Kirk: The async stuff I've built things. Actually, I've taken old EventMachine code and rebuilt it using the async stuff to great effect. The selling point for EventMachine back in the olden days was that it made your code a lot faster. And these days, if you build it with the built-in Ruby async stuff, it's going to be as fast or faster than it ever was on EventMachine. It's really impressive.

Noah: Yeah, it's good. And having Samuel Williams doing that stuff is a big deal. Like, the core team is listening to him, and he's doing a good job. His stuff works well. He's built Falcon, the webserver that works on that; it's good. The one remaining thing that makes it rough is the GIL. And so it's imaginable that Reactors and AutoFibers are going to work together far better than they work separately. But again, this is a whole other programming model. This is not a thing where you just drop it into your Rails app, and Reactors at least are very far from being dropped in Rails. Rails is going to have to do a size of rearchitecture quite at least comparable to what they did for multithreading, which was not a painless transition either.

Kirk: No, it wasn't at all.

Noah: Reactors look like they're going to be at least that bad.

Kirk: Let me throw another one out at you because this is one that a lot of Ruby programmers in particular struggle with the concept of, and that's the static typing. Being that you're from a C background, you understand typing.

Noah: Let's be clear that in C, they may have a little cosmetic type system on top of it, but in C, your typed operators are here's an arrangement of bits where we think this operation is fairly useful, but every type is not actually a type; it's a buffer.

Kirk: Yes, that is true, and that bites you in the butt sometimes. But it's an interesting thing because, from my point of view, I've gone through an evolution in my perspective from not even understanding why we would want static types in Ruby because Dynamic types are fabulous to really being a fan of static typing. And it's an interesting thing because the Ruby 3.0 approach took a very inoffensive approach. It's there, but you can completely ignore its existence if you want.

Noah: So Ruby 3.0, if I was to try and express the unifying principle because there is one behind those three pillars of it, why are the three pillars performance, concurrency, and static typing? Why those three? You could say, "Oh, well, those are the top three things on the feature list." No, they make more sense than that. Matz, who is a forward-looking guy, thinks that what Ruby really needs is more support from large companies and large projects, and I think he's dead right on that. Ruby has been a fantastic way to start your small projects for an incredibly long time. And our biggest source of friction at this point is that if you want to try and take your Ruby or your Rails project into a great, big company, great big companies, especially ones that buy a lot of small companies, their primary exposure to Ruby is going to be by buying up small companies, which if they did everything perfectly, they built their Ruby app as fast as humanly possible because they were building a long series of Ruby apps as fast as humanly possible because they were testing out stuff for market risk. And any extra time that you spend putting into making a highly bulletproof prototype that three people try on and all go "Uh, I wouldn't buy that" is completely wasted. If you are doing it as fast and as well as humanly possible, your Ruby code should be cruddy at best because you're evaluating it for market risk, and putting the extra time into a thing nobody wants is stupid. And that means that when you succeed and then you scale it up just enough, and then the company buys you, your Ruby code should be terrible if you're good. And that means that these companies who buy up tiny Ruby companies are buying terrible Ruby codebase after terrible Ruby codebase if they buy from the best business-savvy Rubyists, I mean, think about that for a minute.

Kirk: Oh yeah.

Noah: That's the system operating as designed, but that means there's a lot of friction with big companies there because what they see is terrible codebase after terrible codebase. Showing that Ruby can scale up to giant companies -- and it's happened a few times like Cookpad has this wonderful, astounding Ruby architecture, like nothing anywhere else. The sheer volume of code that they deal with is --

Kirk: I used to work for Cookpad. So yeah.

Noah: You know about it.

Kirk: I know. Yup.

Noah: Yeah. There's a great presentation on it. I have never worked for Cookpad. But yeah, those three pillars. Ruby starts to slow you down seriously if you're trying to run a lot of servers because its concurrency is not good. You wind up starting a lot more processes than you would have to with something that had a different threading model. You wind up doing that thing where you juggled in Puma, and you have five threads per process, but for every five threads, you need another process. And it winds up eating a lot of memory that can slow you down if you're a big company. And the rest of it is more about the perception of speed, you know, performance as a pillar. I feel like Ruby is fast enough for the vast majority of what we want to do with it, but I feel like the perception of its speed lags well behind its actual speed. And so I was thrilled that one of the things I got to do was to write a long series of articles about Ruby performance because it's one of those things you can point at, and you can say, "No, actually Ruby is fast for these tasks. Here's a piece of evidence." And I feel like the evidence, in some ways, was more lacking than anything about the performance of the language, which is pretty good. Like by the time they announced Ruby 3.0, which was around 2.3 or 2.4, they'd fixed the problems with the garbage collector. The garbage collector was good by Ruby 2.3 or 2.4. It wasn't nearly as good in 2.0. But so dealing with the perception of speed, so you've got the concurrency which handles memory use. You've got the perception of speed plus memory use. And you've got this thing with static types, which is not about scaling to a high-performance level necessarily. It's about scaling to a large number of developers.

If you look at Sorbet, which came straight out of Stripe, which is using Ruby with a very large number of developers, Stripe has this internal thing where they restrict a lot of the least large project-friendly features of Ruby. You stopped being allowed to do things like change your inheritance chain of modules at runtime and things like that, which Ruby absolutely allows but is frankly not a good idea if you're on a large team, and it's hard to keep track of all the pieces. And there are a lot of things like that where Ruby is designed to allow a tiny, smart team of people who trust each other a lot to move as fast as possible by changing things that, in general, aren't always a good idea to let you change. And when that works well, what you get is something like Rails, which is fantastic and better than anything that came before. And when it works badly, what you get is a mess. [laughs]

Kirk: One of the things that I appreciate about static typing just in general is its ability to help me find bugs that you can argue well, those bugs should have been found in your test cases, and maybe that's true, maybe it's not true. But the ability to just have the system say, "Hey, in this code here, you said that you were returning XYZ, but in this line here, you're not," is incredibly valuable. Because I find that it saves a lot of time chasing down bugs that might otherwise be hard to find or not even discovering a bug until your code is running in production and that one weird thing happens yet it gets the one edge case to occur that suddenly you're returning the wrong thing from your method. And if you had been using typing, it would have told you it was wrong. I think that that is going to be one of the features that eventually starts winning people over to the idea of using the static typing because the way that it's implemented it pretty much stays out of your way, and you don't have to use it. So it doesn't limit you in places where static typing might be difficult to deal with or limiting. But at the same time, you can get most of the benefits out of it. And that's the thing that I'm really excited about for the future of Ruby.

Noah: Well, so testing is like security in the sense that if you don't actually know anything about it, you probably ask, "Is this thing well tested?" just like you probably ask, "Is this thing secure?" And it turns out the moment you get talking to somebody where that's their thing, that stops being a useful question. You're asking a Boolean question about a thing that is fundamentally not at all Boolean. It's not a true false. With physical security, you ask, "How long is it going to take a dedicated attacker with X budget to get through it? It's going to take X budget and Y time to get through it. That's how you talk about security. Nothing is ever fully secure. You can secure the door of your house as much as you want; at some point, they take a chance on your wall.

Kirk: [laughs] Exactly.

Noah: Yeah. And a lot of software is the same way, but testing is the same way. It's not that can you reach a given level of correctness? Because the answer is yes, obviously. Take as long as you want and as much budget as you want. You can always take any testing method and get to a given level of correctness. But what's the fastest, cheapest way that I can get to some specific level of correctness? In the same way, if you do everything with integration tests, you can absolutely fully do everything with integration tests, and you're going to be sitting a long time, and it's going to take you a really long time and a lot of money to write it. So when you say static typing, this may convince people, yeah, what you're talking about is a faster, cheaper test for a thing that otherwise you've got to write and repeatedly run a unit test to get. And yeah, if it can catch this common class of bugs really fast and really easily, fantastic, let it. You get there faster; you get there easier; you get there cheaper.

Kirk: That's where I'm looking at it. I was curious how you were seeing it because I think the future is really bright for Ruby 3.0.

Noah: Ruby 3.0 is starting to aim a lot more at larger projects and larger companies, larger teams. And I absolutely get where that's coming from, and I'm standing in a place where that does me personally very little good if that makes sense. I have really enjoyed small companies, small teams, small projects in recent years. And one of the great joys of being an old programmer with a long and distinguished record is I can pretty much decide where to work. And so a lot of the situations that this is optimized for, I'm pretty happy not to be standing there.

Kirk: That makes sense to me. Is there anything that you are working on that you want to talk about or share, or is there anything that we haven't touched on that you think would be interesting to bring up?

Noah: So you know MUDs in the 1980s?

Kirk: Yup.

Noah: Yeah, like massively multiplayer text games. There was a thing called LPMud. It was written by Lars Pensjl. So it's an LPMud, and it spoke LPC, which is not very much like C, but it is an interpreted C-like language. This was in the early '90s. There was a rewrite of LPC called DGD that you've never heard of. Like, you can count on your two hands the number of professional engineers that have really ever touched it. So this one random guy who wrote it has been working on it since then. So if you think of programming language evolution as you've got horses, and cows, and zebras, and things like that for these other relatively mainstream languages, this is a platypus. [laughter] This one guy has been evolving it in its own direction the entire time. It does ludicrous things like you can recompile every object in place Ruby style. But you can also do…think of a database transaction, but you stick the word atomic in front of a method. And the entire method is effectively a database transaction but even for things like network I/O, and even for things like global variable Reads/Writes like, weird stuff. You can recompile all your objects in place, and that's atomic too. You could partway recompile all your objects, find a bug halfway and unroll the stack on recompiling all your objects. Like, that's how completely this is a different programming model. So what I've been doing is it turns out one guy started a company to make commercial MUDs on top of this thing. And they've got a 20-year old gaming engine that my paid gig lately has been retooling, and documenting, and fixing up this old gaming engine written in this language.

Kirk: That's really cool.

Noah: It really is. So I'll say if there's something weird that you did in your youth that you didn't figure there was any possible use for it later and even if you have very good reasons to think that, one of the joys of continuing in this way is if there's ever an opportunity for that 20 years down the line, you'll be in a good place to take advantage of it. So watch for that, keep a few feelers out.

Kirk: [laughs]

Noah: I was also the first guy to ever put together a documentation website through DGD because when I got there, it was about ten years old. Again, almost nobody had ever used it. And I learned about it the way everybody learned about it at that point by reading ten years of mailing list archives, but I put them together into a website.

Kirk: Neat. I remember LPMud. I used to hack on that stuff. VAX/VMS, there was a MUD system called Monster for VAX/VMS systems that I hacked on a whole bunch.

Noah: Circle mode was my intro.

Kirk: Yep. Small world. That's awesome. So what's this thing called?

Noah: So the language is called DGD. Felix Croes, the guy who writes it, goes by the handle Dworkin, and it's Dworkin's Game Driver (DGD). And the game engine is named SkotOs after the company. So ran a couple of games, Castle Marrach. What were their other early ones? Castle Marrach was their big success, and it ran for 20 years on DGD. It's still running. You can go log into Castle Marrach today. Yeah, it's still around.

Kirk: Wow.

Noah: And you can pay them for a premium account. It's still a commercial MUD. It's still running on this commercial MUD engine. But the commercial MUD engine is called SkotOS will get you to this thing I've been working on.

Kirk: Oh, that's really cool.

Noah: They had five different competing user authentication systems, and I've just torn out four of them, but the other one works. [laughter]

Kirk: Awesome. I'm definitely going to have to check that out.

Noah: Please do. I need to turn this into a talk. I have been building a library system for a language that doesn't have one as a paid gig. I'm building the first API documentation tool for this language because there has never been one. And I think it's from 1992 or 1993. It's actually really cool to work on the platypus of languages. [laughs]

Kirk: Yeah, definitely. I'm going to have to check that out. Thanks for mentioning it. I hope some of the other people who are listening to this check it out too. That sounds like that could be, if nothing else, really interesting.

Noah: I'm going to have to turn this into a conference talk. I just am. [Laughs]

Kirk: And hopefully, in the not too distant future, we'll actually be having conferences where we can mingle in person again.

Noah: Oh, I hope so. I feel bad talking about it because RailsConf is trying to drum up -- And it's not that RailsConf is bad. RailsConf is amazing, but any conference that's not in-person, I'm just feeling erm -- RailsConf is fantastic.

Kirk: It's that hallway track. That hallway track is really what you miss.

Noah: Yeah.

Kirk: Well, I think we'll go ahead and wrap this up now. This has been a lot of fun. I've really enjoyed this. I've really actually enjoyed the fact that somehow despite having some overlap in our experiences and our age and everything, we've somehow never managed to interact with each other before this. I'm not quite sure how that happened.

Noah: You keep finding really cool people that have been hiding somewhere the entire time. [chuckles]

Kirk: And I haven't even really been hiding, and neither have you.

Noah: No, I sell books online. I'm easy to find. [laughs]

Kirk: Yeah. It's just wild, wild, and fun. So anyway, thanks to everybody else for listening to us chat here on Polyglot. You can find us on Twitter @PolyglotShow. This is Kirk Haines for The Relicans. Check us out, and thank you very much for listening. Thank you, Noah, for joining me and chatting. This has been a lot of fun.

Noah: It has. Thank you.

Jonan: I want to remind you all that New Relic and The Relicans are going to be at our upcoming user conference, FutureStack coming up on May 24th. You can stop by and read about it. We would love to have you there. Hope you have a wonderful day.

Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on In fact, most anything The Relicans get up to online will be on that site. You'll also find news there of FutureStack, our upcoming conference here at New Relic. We would love to have you join us. We'll see you next week. Take care.

Discussion (0)

Forem Open with the Forem app