Steve: what do you mean by work? Because like if, I mean like when a good chunk of my unit tests are passing, then sure that period of time may happen faster than developing a rust thing. But if then I also factor in the time of like the bugs that got filed in the first two weeks that I have to go back to and fix.
Whereas the rust code tends not to have that kind of effect. Like yeah, I've paid a, I paid a larger upfront cost, but my overall development time is actually shorter.
Andrew: Hey, before we get started we want to remind you that we have a Patreon. If you want to hear the full episode, you'll have to become a member over there. You can also support us by going to our merch shop and buying one of our shirts.
And with that, let's get onto the episode.
Andrew: hello, welcome to the Dev tools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew, and this is my co-host, Justin
Justin: Hey everybody. Uh, our guest today is Steve Klabnik. Uh, Steve is a colleague at Computer Engineering. Uh, ooh, let me just restart. Hey everyone. Our guest today is Steve Klabnik. Uh, Steve is a coworker of mine at Oxide Computer Company. Um, he was formally on the rust Core team, uh, co-author of the rust book, uh, and a lot of other things.
Uh, Steve, it's really great to have you on. Uh, is there anything else you'd like to tell our listeners about yourself?
Steve: Yeah, thanks for having me. I don't know, I, uh, as I'm approaching 40, I'm like more and more generic with the stuff that I say because as things have piled up over the years, so, I don't know. I did some ruby stuff, I did some rust stuff. I've been working out a lot lately. That's, that's all I gotta say right now, I guess.
Yeah.
[00:01:38] Getting into Rust
Andrew: So h how did you end up on the rust team? That seems like a, a, a big accomplishment to h ave.
Steve: Yeah. So, uh, back in 2012, I had heard of this little programming language that was kind of like C and OCaml put together. And I was like, those are two things I'd like, so I should check that out. And in general, I've been sort of a programming languages enthusiast and at the time I was very heavily involved in the Ruby and Rails, like both of them world.
Uh, and so I was kinda like looking for my next big thing. And so I, I heard about this and I heard it was sponsored by Mozilla and that was interesting to me. So I checked out the website, tried to build and run Hello World, and it didn't work. And I was like, okay. They say come to IRC chat to answer to get que help with things.
Um, I know what that's like, but I'm also an adult. I have self-esteem. Sure I can join in an IRC chat and ask for Hello world and they're probably gonna like, you know, ream me out, but like, it's fine. Um, and so I did and they were like, Oh my God. A new person. Yeah, that's our bad, the documentation is a little bad.
Uh, this is how you actually do it now. And that's cuz something changed two days ago. But like, please just like an, you know, if you got any other questions, like super happy to answer. And I was like, holy crap. Uh, these are like nice people who are like helping me instead of calling me an idiot. Um, I wanna like hang out with these folks.
And so, uh, I just kind of continued to do so and then eventually, you know, kind of like worked my way up from there. But that was the like original way of me finding rust. I think that. In terms of like getting on the team, uh, one of the things that I personally value, and one of the things that, at least at the time, I won't say necessarily yes or no about right now cause I've been out of it for a while, but like the Mozilla valued very strongly was documentation.
And, uh, so I became like the docs person because it was an interest of mine and it was also something that they really needed really badly. And so, uh, I kind of just like made that happen that way. So that was sort of also my interest, like my personal interests and skills lined up with something that they needed.
And so, you know, we just, just like all good open source stuff, right? You like, hope someone comes along. I was the person that came along, so, uh, you know, that's, that's how that worked out. Yeah.
Justin: Yeah. Yeah. How, how was the rust community, especially when you got started, how did it contrast with like the Rails community or the Ruby community? Was it like a simpler vibe or was it, there's something that struck you about how they approached it differently?
Steve: Yeah. I mean, there's a couple different things. The first of all is that like Rails was at the time like the things startups did by default. It was no longer the like tiny little project struggling for relevance. It was General Motors, like the man putting on a suit and going to work every day. And even though the community's like not, I would say like boring as how they would describe that kind of thing as that it's still ultimately like, like these are real businesses making real big money and like this is a serious thing and like, you know, thousands of people use this and like all that kind of stuff.
And rust at the time was almost the exact opposite. Like, I don't remember how many people were in that IRC room, but it was like probably around a hundred, like not a thousand. Uh, and so, you know, with community being a lot smaller, um, you know, I think that leads to a lot of big differences. Like, uh, I, I.
had made a joke that like learning Rails at that time was kinda like starting a soap opera in like the seventh season. It was like a thing someone said to me at one point and I was like, I think it's very accurate. Like, you know, the culture was already strongly formed. There was already the seven different groups of people that kind of lowkey hate each other, but they're all, you know, trying to make it work and all that stuff.
And Rust is a much more like unified place where everybody was like working on the same thing and kind of on the same page. And obviously there was still some arguments, but it definitely wasn't like, you know, small communities are just very different than big ones. And so irrespective even the specific good and bad things about both of those communities, I think that was at the time, especially the sort of overarching thing.
And uh, you know, it's, it's nice or at least for me, I've learned that I often enjoy getting in on the ground floor of a thing, not necessarily the like actual ground floor. Like I am, I'm employee number one. I'm not a co-founder in sort of like startup terms. Like I was the 17th employee at Oxide. I there and there's no reason I didn't co-found oxide cuz like that's just like not who I am, but I also don't really like working in thousand person companies or whatever.
Uh, and so, you know, rust was kind of like closer to that sort of aspect of things and that kind of fit in with my like, uh, you know, the way that I like to work on things. Cuz you can have a much bigger impact on things when stuff is small, like, as opposed to being a cog in the machine. And it's nice to be a cog in the machine in some ways too, but just like, especially in that moment, that was kind of where my head was at, was like, I can't really do a whole lot more in Ruby and Rails, but like this is a nascent thing that's just starting to grow.
And so I could have that impact and you know, here I am now so.
Andrew: Yeah. I, I, I think that is kind of inspiring for like newer developers, cuz like I meet a lot of people that are like, oh, I want to get into oss. But it's so hard. Like, it's so big and it's like, I go, it's not really though, like there's problems abound and people do not. So like, if you want to go out there and add docs to something that is a totally valid contribution, like, I literally just merged a docs contribution and thank to the guy.
So like, if that's some, like if you wanna get into oss, that is the best place to go.
Steve: Yeah. I think also another thing too is that uh, people sort of like over rotate on it must be me and not the project. Like some OSS projects are just insular. Doesn't matter how amazing work that you do, they're just not gonna like accept you into whatever. Cuz that's how they're run. But that's like a them problem, not a you problem.
But if you pick a project that's like that for your first try and then you get super discouraged, like that's also a thing to sort of remember And it's really tough to be like, oh yeah, you feel like you failed it. Getting involved with one project, TA better do another. But just like, that's actually also the case too, is that some projects are just opaque and insular and you know, that's, they like it that way and that's totally fine, but it does mean it's like not a great place to start.
Um,
Andrew: Yeah. On, on every one of my GitHub notifications, if a person's like, oh, this thing is broken, my first response is just please submit a pr. Uh, and I have felt the other side of it too. There's a particular project I've tried to contribute to about half a dozen times now, and every single one of my PRS has been stricken down.
But I, I understand that they just run their, run their thing differently and want a, a more holistic approach. So it's definitely something you ha you have to take that feedback with a grain of salt cuz you could be doing amazing work and it's just like, it just doesn't quite fit with their roadmap or their plan for things
Steve: Absolutely.
Justin: Um, sometimes it's just outta scope of what they wanna support, cuz it's like, that's another thing that's easy as an OSS contributor. It's like you're writing code, but like, You're probably not on the hook to maintain that code. Right. So a lot of the people who are maintaining the project are responsible for the, you know, nifty feature that you add no matter how well written or whatever.
Andrew: As a maintainer, I love patches. Minors make, give me a lot of stress and anxiety. just, it's cuz it's like, oh, new feature. Like, do does this fit? Do I care? Do I want to support this?
Justin: Yeah.
Steve: absolutely. And there's also the sort of like, yeah, like do I even know, like cuz sometimes a project needs help cuz they don't know how to do a thing. Like I use Windows, so I get a lot of, a lot of times like people are just like, I would support this in Windows, but I don't know how. And then the problem is like, even if you do come up with a patch to support Windows, if I'm not planning on becoming a maintainer on the project and they don't know how to keep the Windows support going, like is, I mean that might be useful for a little while, but that's like not the same too.
And so, uh, you know, and that's like sort of nobody's fault. Like they don't use Windows and I'm not maintaining the project. So like, you know, it just is what it is. But that's also definitely a way that even when both sides want to like have a patch or would be willing to accept a patch, doesn't always mean it's like right for the project regardless.
[00:09:38] Attempting Contribution
Justin: Yeah. I think an interesting like note here is that like all software systems are human systems, like fundamentally. So it's like, you know, even as we're starting to talk about like the sort of vibe that a community gives off or like how they approach, you know, your contributions or like the things that you have to think about when you're making a contribution is like, is this in line with the project's vision or whatever.
It just like all goes back to like, all this software is like really has people as a fundamental aspect of the whole thing. And you know, and especially true, like when you get into companies and stuff, it's like the people dynamic matters a lot. Uh,
Steve: One of my favorite stories from the old days is about why make files have tabs for, uh, indentation. . So like the, the, the dude who wrote it, I forget what his name is, he basically used tabs cuz it was convenient and he liked it or whatever, but he didn't sup it didn't support spaces. And he like wanted to change it to spaces or to be able to use spaces instead of tabs in some fashion by default.
But he was like, . I looked at it and I was like, you know what? Like hundred people use this tool. I don't wanna cause them any additional stress. So we're just like, not gonna do that. And then all these years later now there's like, you know, millions of people that have like, suffered through that particular thing.
And that was just like a, like yeah, a very human decision about how to maintain a project and like, can't really fault him cuz in the seventies or whatever, like, holy crap, a hundred people are using my project and distribution is not the same. And like, you know, like there's a lot of infrastructure that we have now that would've made that choice much easier.
But, uh, man, it's a problem. And then like on a similar kind of like, uh, project, but also the social sides of things, uh, GNU make make actually has a good error message if you use spaces instead of tabs, but only if you use eight spaces. It won't detect any other number of spaces, but only eight. And so I was like, you know what?
I'm a good citizen. I do open source. I'm gonna add in a me, uh, I'm gonna send in a patch. So I, I, you know, made a thing, I signed up for a Savannah account and like did all that junk and I wrote up a patch that was like gonna also check for four spaces. And I was like, Hey, I could generalize this to be like two, four, and six or like, you know, whatever else, but like, I'd like to hear about it.
And this person, I had one response and this person was like, I'm worried about this breaking existing code bases. And I applied, no, no, no. This is, this is in the error path. We've already determined that we have an error. The question is how do we print out the error that we have? This has zero compatibility issues, just like, you know, whatever.
And then no response. And it's been like six or seven years now, and I'm just like, man, like I could've, you know, it could have helped out. A bunch of people get better error messages. They don't have to go on stack overflow or whatever, but, you know, it's, it's hard. So I don't know. Why that patch was rejected for real.
But you know, it was just like, all right, I tried. And you know, even me with like zillions, there was like a time where, and this is cause I've been on GitHub since literally the beginning, but like there was a time back in those like Ruby days where I was like, the person who was in the most organizations on GitHub period, like I was in like 17 or 20 or something.
And that was like the next nearest person was like 16 or something. And so, you know, even me like that guy still couldn't get a passion in a, in a make and like, that's not my fault. But if I was a beginner, I can totally see how people get super discouraged if that was my first interaction with doing anything.
Open source.
Justin: Yeah. Yeah.
[00:13:05] Why Rust
Justin: So, yeah, let's talk about rust a little bit. Um, so. Some of our listeners may, I hope all of our listeners are familiar with rust, but some of them may have never used it before. So let's, let's talk about the language a little bit and maybe compare and contrast with that thing with Ru rust with like existing languages.
So I, I think in a lot of circles rust is, is talked about as a systems programing language and we can address that in a little bit. Um, other systems, programming languages like c and c plus plus have been around for years and years and years. Um, why would a developer choose rust over something like c and c plus plus?
Steve: Yeah. So I think there's a couple aspects of this. So I wanna mention a thing that we'll get into afterwards and then I'll answer your question directly. But like, I think part of the question is like, it's actually broader than that, but that's a, a debate that's like currently raging, but I think it pretty solidly comes down on the other side.
But in terms of the c and c plus plus angle, rust allows you to do everything C and c plus plus will let you do, but it helps you do those tasks significantly more. And like, what I mean by that is when you're doing these kind of like low level work, although I kind of don't like the high level, low level thing, but whatever, let's just accept that's like good for now.
If you're doing low level. You have to use very sharp tools and sharp tools can sometimes cut you. And there's like a weird balance there. Um, additionally this space hasn't really seen a whole lot of like new programming languages in a long time compared to many other fields. Uh, fields many other like aspects or like, like design points in the programming language design space.
And so they also tend to be like much more old school and therefore like harder to use if you weren't doing them since the nineties. And so Rust, kind of like, one of the things Rust does is it sort of brings a, let's say 2010s era development experience to a space that is pretty solidly stuck in the seventies and eighties.
And even on that alone, like there's a lot of people who are like, I don't really care specifically about rust versus c plus plus on the language merits, but the fact that there's a developer experience that is more familiar to me or is like just. Easier as opposed to harder is, makes rust worthwhile. So I would say that's definitely one of them is like, if you're looking for that power of scene, SQLs Plus, but you like have used NPM before, you may prefer rust solely because it's like vaguely more familiar to you.
Um, and I think that's a good reason to use tools like familiarity is incredibly important and a, and an actual reason to use something. Cuz if you're trying to get something done, you aren't trying to learn something necessarily. And so using something you're more familiar with can help you get the thing done faster, which is your actual goal.
Um, the second reason though is like very similar to, uh, I, I like to make tool analogies, uh, as many programmers do. So there's like circular saws, right? And like band saws, you got a spinning blade and you know, James Bond is slowly being lowered towards it to, you know, cut 'em up or whatever. There's this really interesting tool called the Saw Stop.
And what it does is it, like it detects if I forget exactly how it works, but it's, it's something like, you can do it with your finger or a hotdog, but like not anything else. Right. And it's able to detect that, like something fleshy is approaching the saw and then it will stop the saw immediately before it gets cut.
And like the CEO does this demo and he's like, I hate doing this demo every time, but I still do it. Do where he stands next to the thing and he'll put his hand on the table saw and it will drop outta the way. And he's like, look, I got like a teeny little cut, but like my finger is still here. And so rust is kind of like that, whereas C and C plus plus or closer to a standard saw in this particular instance.
So like it's, it's more about, it's not about like, it stops you from doing the thing you need to do. It's like it's got these safeguards built in so that if you make a mistake, it'll be like, hold on, hold on, hold on. Let's like, let's double check this thing here. And that can be especially useful when you're new to saws and you've never been sawing before and you don't have the muscle memory of like keeping your thumbs off to the side, right?
Like. Uh, and so that's also I think another sort of great reason to use it. But additionally, like, you know, I sort of framed that as a beginner's thing, but also experts. So like, you know, I, I, uh, am have been around rust for a while and I've been programming c basically my entire life, even though I don't know if I'd say I'm good at it, but just like I want tools to take the cognitive burden off of me, even though I'm an expert.
I don't wanna have to think about a bunch of that crap all the time. I wanna compiler to yell at me when I make a mistake and then fix it and move on with my life. I don't want to have to constantly be considering all of these like things about like, am I doing this right or not? Or am I making a mistake?
Or like, am I about to cut myself? It's just not really a thing. I wanna like build tools and processes to make it so that the tool insurers, I don't cut myself. So that way I can think about my problem and the work that I need to do as opposed to the details of the specifics of the thing that I'm doing.
Andrew: Very similar arguments for JavaScript versus type, type script.
Steve: Yeah, absolutely. And type systems are a big part of. that in Rust specifically, uh, for a lot of reasons, but also just I think in general, um, I definitely don't, uh, I don't know if I'm gonna like super, want a program in languages without types again, but it's not, cause I think that languages that don't have static types are bad.
It's just that like static type systems have gotten a lot better and mainstream languages support of 'em has gotten a lot better. And so to me, the trade off has changed. And so, uh, you know, that's, that's like a personal preference these days. But like, I got a ruby like tattoo, so I don't hate dynamically type languages.
It's just, uh, you know. Yeah, absolutely.
Justin: Yeah, definitely. The, the, the type systems have improved a lot and, and it's like more, even just like reading code, there's a lot more like semantic meaning that's been added to them. And I think like even getting into rust where it's like it gets pretty advanced and the things that you can express. Um, so, uh, one of the things that I'd like to talk about next is like some of the defining features of rusts.
Um, Uh, I'm, I'm gonna oversimplify this, but like, there are like two broad like memory management strategies and programming, right? So you have like manual man memory management where you're just like, you're keeping track like yourself of like what pointers exist and like how things are accessed. Like, mostly.
And then there's like garbage collection. And again, very loose generalization here there's more and more nuance, but, um, so things like JavaScript, you don't, you don't really think about memory too much until performance starts suffering cause of the garbage collector. So could you talk a little bit about like, some of the features of Rust, including sort of like, things that, like really, uh, things like how it does memory management, how that like, is different than, than, you know, languages that came before it.
Steve: So I wrote a blog post a couple years ago that got a lot of people very angry, but I still like it and it answers this question particularly. So, uh, maybe I'll look at show notes or something, but I, I like to say that Rust has static garbage collection, and this tends to make everyone mad. But what I mean by that is Rust doesn't have manual memory management in the sense that you, you very rarely are like, please give me memory and then, okay, I'm now done with the.
And it doesn't have garbage collection in the sense there is no garbage collector running in the background. So like for people that aren't maybe as like, into the details of like how your programming languages are implemented, uh, garbage collectors are sort of like software that's running while your program is running and it's like cleaning up after you, it's kinda like running around behind you and like fixing stuff up.
And there's lots of different ways that could be done with a ton of different trade offs. And it's a whole big giant topic, but like fundamentally it's some software that's kinda like running in the background, this code that you didn't write that's, that's like making that happen. And so what rust does is rust kind of is able to say, it's able to do an analysis, a compile time that says, okay, here's where your memory is like being used, and then here's where it's not being used anymore.
And it sort of like inserts the calls to free and, and malloc as the name and ce, but like it sort of allocates the memory and deallocates the memory the same way. that you would in a, in a by hand, like manual memory managed language, but you're not writing that code anymore. So it's sort of similar to that GC case where you're not writing that code.
And so I think this is one of the biggest reasons why, uh, it's sort of like more familiar to folks that are coming from a GC language because like, you don't see calls to, please give me memory and please free my memory. It's like a variable comes into scope and it gets the memory allocated. It needs, it goes out of scope and the memory gets deleted.
And you might be like, well, isn't, why doesn't a GC just do that? And the answer is like, there's a lot of it. There's a lot of, like, imagine you have one object that references another object and that second object references the first one. Uh, where do you insert that call to free? Because if you did it on one, then this would be invalid.
And if you did to this one, that won't be invalid. And so a garbage collector, because it's app operating at runtime is able to sort of like wait until both are no longer used and then go, okay, I can get rid of these both at the same time. But it does that via sort of like dynamic analysis and rust's sort of like model precludes some patterns where you do things like that because it'll sort of throw its hands up in the air and be like, I don't know how to statically analyze this.
And there's tools and techniques you can use to do it kind of anyway. But like, the point is, is that like a GC kind of fundamentally allows you to say, write the code the way that you want and I'll make sure nothing goes. and the trade off Rust gives you is sort of like, I won't let you write the code however you want, but like 90% of the time what you want works with my model anyway.
So like you get efficiency gains because you don't have that stuff running around in the background, but you're, you're giving up like a little bit or depending on how you code or the way your brain works, like a lot of the style of code that you're used to writing. Um, and so that's kind of, rust has chosen a trade off.
It's not universally better, it's not universally worse. Um, I do like it the best, but, uh, I'm biased. So
[00:23:11] Compiler Feedback
Andrew: So while you're developing, does that like surface an error? Like, oh, you're doing something weird with memory that I just can't handle? Or is it like a runtime
Steve: yeah. It'll, it'll, it, it, so there's always asterisks on everything, so I'm just gonna stop saying there's asterisks, but please treat all further statements as having asterisks. in general, 99% of the time it will basically say, Hey, this reference is alive till the end of the function, but is pointing at something that dies in the middle of the function.
So, uh, you gotta fix that and gives you the ability to do whatever you can build stuff that also, there's some standard library types that will give you kind of a runtime check thing, but those are used more rarely because compiled times is better than runtime for pointing out errors. So you only do that in like certain specific circumstances, but generally, yes.
It'll, it'll just be like, I don't understand what this is, here's what I see happening, please fix it. And then you gotta kind of fix it. Um,
Andrew: That's awesome. Yeah. My, my l my brief stint in systems programming is me coding C in college. And it was a nightmare. I can't believe that was the first language that they tried to teach us. Like, I look at that and I go, pointers, why would you teach a, a freshman that, uh, but memory management was like the hardest thing to wrap my head around.
And the fact that it gives you like nice compiler errors that basically say, Hey, you're doing something wrong here and here is so much better than seg fault. Go open a debugger that you, that was built in the sixties and you have no clue how to use
Steve: Yeah, and this is one of the big debates on like, is Rust easy to use or hard to use? Is that, I think that different people experience that in different ways. So for example, some people just seem to like really not like the idea that a compiler can tell you it's wrong. Like compilers should be seen and not heard.
And so they like end up resenting when the compiler points something out to you and therefore get frustrated and don't like. Whereas I personally am like I see it as a tool to help me work faster. Like a lot of people are like, rust slows you down so much because you have to have this compiler complaining at you all the time.
And I'm like, rust makes you work faster cuz you have this compiler complaining at you all the time. And I'm not entirely sure like that. That's like a scientifically resolvable to the correct answer more than it is like a personal preference. But you'll see people expressing literally opposite opinions about the exact same scenario.
And I think a lot of that has to do with sort of your frame of reference to like what you want tools to be in your development workflow.
Justin: I definitely think it's like, it's always a trade off that you're gonna pay. It's just when you pay it. So rust is like, you're paying it up front, right? So the compiler is telling you, Hey, this, this is gonna cause you a problem. Where if you're doing it in c and c plus plus, it might compile the. , and you might hit a SEC fall, you might not until like it's in production and some inopportune moment, your program crashes or there's a buffer overflow and like somebody figures it out, like attacks your software, you know, like.
Steve: I was making the joke the other day about you have to consider the total cost of ownership, which is very silly given that ownership is like a concept in rust. But like if I think back to my Ruby days, like this is another one of those perspective things. People are like, it takes forever to get something to work and rust.
And it's like, well what do you mean by work? Because like if, I mean like when a good chunk of my unit tests are passing, then sure that period of time may happen faster than developing a rust thing But if then I also factor in the time of like the bugs that got filed in the first two weeks that I have to go back to and fix.
Whereas the rust code tends not to have that kind of effect. Like yeah, I've paid a, I paid a larger upfront cost, but my overall development time is actually shorter. And this is something that our, not to like get too into brain science cause I'm not that great with it, but my understanding is that due to.
Pre industrialized society, we are really conditioned to like care about the short term in opposition to the long term. And we do a bad job of weighing like short-term gain versus long-term gain. And so we'll perceive this as being a faster thing, even if it takes longer, just purely because of the way that we experience it.
Um, and so that's been like a really interesting, uh, source of a lot of arguing on the internet, shall we say. Um, about, yeah, like is Rust Ex, does rust hurt your development velocity? Velocity or not is like a thing you'll hear people talk about. And that's just like, the way that I see it personally is like yes and no at the same time.
Um,
[00:27:31] Choosing Rust for new Projects
Justin: Yeah, for sure. I've, I've seen some articles recently. People were like, oh, you know, we built our startup and rust and like, we won't do this again, or, or whatever. And it's just like, you know, it's, it's all about trade offs, right? It's like understanding, like whatever you're trying to achieve. But like there's a certain, if the certain, like, I think level of like safety and correctness is important to your application, which it should be, and a lot of times, but like, you know, it really makes that trade off like more worthwhile because you have like more confidence, you know, when something's compiling that it's actually kosher
Steve: This also gets back to the thing I was saying about familiarity earlier too, is I think this question is very different because like I, I replied to that very thread and I was like, hello. I work at a startup named after Rust, and we use Rust after all of our stuff and it's working out great for us and we wouldn't have it any other way.
And someone responded, well you are Steve though. And I said like, yeah, but I'm one of 50 employees and I'm pretty sure the rust of them aren't also Steve. Um, and like, but this is because like, not that everyone at Oxide is familiar with Rust when they start, but like we are faster at spinning up tools and rust because we have familiarity with rust and so we're not struggling.
Like one of the things that the points they made in that post was that they were struggling a little bit cuz they were still learning while they were trying to build their startup. And it doesn't mean they, I think they made the wrong right decision. Like I'm not trying to judge their decision making process.
But also another subjective factor that comes in to answer these kinds of questions is like me spent literally the last 10 years of my life using Rust is not gonna have the same struggles as somebody who learned it six months ago. Even when, even if we both started an identical startup the same day, the the outcome will be totally different.
And that's why I think familiarity is like a good reason to choose the technology sometimes cuz like, you know, if you ask me to use a programming language I'd never used before and also build a company at the same time, I would also probably say that development velocity sucks, even if it's a thing that like is traditionally known for being a fast way to do, uh, a startup.
So yeah, totally.
Andrew: Yeah, so, so many parallels with type script. At our company, we use type script and people will come on and, and be like, ah, I hate this. I don't know how to do anything. And then I end up helping them through like lots of weird, opaque type issues. But, uh, they, they, they get up to speed eventually
Steve: Absolutely.
Justin: I think there's a lot of like mental, mental model mapping here. Like if you're used to just using languages that use garbage collection and you're not used to thinking about memory management as a, as a concept, and then you start building a new product where you have this. Change in perspective that you're trying to tackle at the same time you're trying to figure out your product, that's gonna make it obviously much harder.
Right? It's like if you were only ever use object oriented programming languages and then you like started a new startup in a functional programming language, it's probably gonna be a little rough, you know, like out of the gate.
Andrew: Yeah, let's try out Lisp. What? What
Justin: yeah. Like do one thing at a time, it's like start a startup or try to learn something, but maybe like, you know, reduce the set of, of new things tracking at once.
Um, so we, we've been talking about like the sort of applications of Rust rust at a, like a very high level. And I mentioned earlier in that first question about like referring to rust as sort of like a systems programming language, but, but maybe that's not even truly fair given how much rust is developed.
[00:30:45] Where to use Rust
Justin: So let's talk about it like rust more broadly is like, what, what types of programs, uh, is rust really well suited for?
Steve: so I'll get there, but I'm gonna go on a small diversion first, the, especially the early rust community. But I would still argue today as kind of the confluence of these three audiences. And the first one is those systems folks. And the second one is like functional folks, and the third one is Ruby, Python, JavaScripts Pearl PHP folks.
And so each one of those kind of like brought their own perspective to how Rust sort of developed along. And so one of the things that makes Rust kind of like weird and interesting and hard is like if you have, if you've worked in functional languages and scripting languages and systems languages, rust isn't gonna be that weird to you, but like not that many people have done that.
And each one of those different audiences has different challenges when it comes to learning rust, uh, because they all struggle with something slightly different. Um, and so I think we're seeing that being expressed at a little bit of a higher level now with this. Like, what is rust good for thing?
Because like if you go on Hacker News and you read a thread and about web development and Rust, there's gonna be a whole pile of people that are gonna be like, you would never use C to write a web app. Why would you ever use Rust to write a web app? And. eight years ago, I would've like mostly agreed, I would've been like, I don't really think rust is a great choice for a web application, but you know, whatever.
But now like I think rust is kind of a good choice for certain kinds of web applications, . And some of that is due to the ecosystem. Like people have shown up and they do web development and they're learning rust because they want to get into systems programming or they like see it as system language.
They learn to do that. But as we said earlier, learn one thing at once, not two things at once. So what are you gonna do? You're gonna build a program that you know how to build already a website with your new language. You're trying to learn rust and so you end up with people building web stuff in rust.
And there's been enough of those folks cuz there's a jillion web developers that there's now an ecosystem of. Yeah, there's, there's like six different frameworks that you could vi build a web app in Rust. And I wouldn't say you're using like an obscure hipster framework. You're using like one of the well-known ones.
And so with the support of the libraries and also some language changes that have happened in the last, you know, since 2015, like I think it's like much more feasible to do so now than it was back then. And so my personal opinion has kind of shifted, but what I would say is that like rust has had this pervasive attitude of like bending the curve.
So it's like if there's a trade off, if we have a, and we have B, is there like a C that we could like take the middle point in that line and like drag it up to be part of the way over there. And so the thing with Rust makes some choices that put it firmly in that systems category, if you can even call systems category.
But whatever, like the point is, is you can write an operating system with rust more easily than you could in say Ruby. Uh. , but like Rust also has this kind of range that's confusing because traditionally, you know, as you said, like programming and C is kind of a little rough. And so you would only want to make that choice if you had to make that choice and you'd want to use something more convenient.
And this is the, the way a lot of people say like, rust isn't good for web apps cuz garbage collectors are convenient and like I'm looking for convenience writing web app. But as people sort of get used to this mental model of this kind of like other additional way to deal with writing programs, they're also still finding it very useful for writing applications like web applications.
And so they're doing it cuz like, like I use Rust to write stuff I would use for like system scripting tasks cuz there's a couple packages in the standard library that are good enough that I can bang that out pretty quick. And it's just like not a struggle for me in the way that it would be for C++
um, there was a, there was a thread on Hacker News yesterday where people were arguing about, Is see your c plus plus better And someone said, show me your C code for writing this little sample problem and I'll show you the c plus plus code for writing the sample problem. And it was take, take input on standard in reverse it and then print it out.
And there was a couple different submissions. I thought they were all interesting. But the deal is, is that like in rust, that's like a one-liner cuz like the standard library is just so much richer than in c plus plus and, and using packages, external packages is so much easier. Not that you need it for that task, but it just like compounds onto that thing.
And so it becomes significantly more ergonomic for use cases that are not your traditional systems cases. And like there's other aspects of rust, like everyone talks about the memory thing cuz it's the most novel part and it's also kind of what early rust marketing sort of trumpeted, but like no null.
Like I don't want to use program languages that have null anymore unless I have to. Like for me that's just like a like. We're, we are friendship over with null. Like I knew friends with some types and like, uh, you know, that doesn't have to be, that's totally orthogonal from the GC to non gcd access, but just like, I just like think null is bad and like ideally I wouldn't have to use it.
Sometimes you do, like, you know, I'm not saying I never program the languages, don't have them cuz I would basically only be able to use rust than a couple other things. But like, I think in the future we're gonna see that as a trend for languages all across the memory management spectrum to sort of like go away.
Uh, and so there's these sort of other ergonomic aspects of. Rust that are appealing to folks. And so they're using it to write literally everything, command line tools. You're seeing tons and tons of command line stuff be redone and rust. And that's like one of the, I think, the best possible use cases. Um, I recently checked in with the, uh, core utils project, which is trying to rewrite the, the Unix core utils and rust.
And like they're to the point where you can take a debian and build the Debian from scratch with those rust core utils and everything works. You can build a Firefox, you can, all that stuff just drop in like totally fine. Um, and so like, that's like a, could replace all your basic command line tools with rust equivalence today.
Um, and I think that's a really cool, interesting, good use case. Um, the, the web stuff is interesting. I think that it, there's definitely a lot more caveats there, but those caveats have been reduced over time and are reducing more and more over time. Um, . But, uh, no, that's definitely like a good one. Uh, embedded development, what we do at Oxide, you know, at least in part we do the web stuff at Oxide too, but like the embedded development stuff, everybody is super, super on board and loves that.
And we have a lot of folks who have a very deep bench with writing embedded code and other languages and they're not interested in going back. That's obviously some amount of selection bias, but just like the point is, is like, I think it's a very good use case. Um, and just sort of almost anything, I just kind of by default reach for Rust cause I've invested the time to use it.
And so that sort of mirrors the, like when not to choose rust, like as we sort of already covered, you're, you're trying to start to do a new thing and you also wanna learn Rust. Probably not that great of an idea. Um, rust does take a certain amount of dedication to learn and by that what I mean is people talk about the learning curve being steep in rust.
And that's true, but it's also flatter. . We don't, we don't like have tools. I can't draw you a graph, but like, you know, a, a sh a hill could be very steep, but ultimately, you know, not very tall. Whereas a mountain can be like very tall but not very steep. And those are very different journeys. And so rust is closer to sort of like a 10 foot wall you have to climb over.
Like yeah, it doesn't really help you very much getting started, and rust sort of does, but like, whatever the point is, it's very difficult. It's at the start, but once you're on the top it's like totally flat. And so you sort of can like reach that level. I think it like takes more effort, but you get there more quickly and there's not nearly as much to go on afterwards.
Whereas in a lot of languages they're easier up front and then you get in like the dark magic corners of them and you find out like, okay, there's a giant hill up here that I can't like climb over. And so. that means that like some folks are gonna struggle to learn rust. And if you, if you try to learn rust and it doesn't click with you, that's a great reason not to use rust.
Um, like, just in a very real sense, like, you know, if, if you don't like it, I think that's a great reason to use something else. Um, another weird phenomenon we've noticed that I would say to those people though is that there's a bunch of people who have tried to learn Rust, said, I don't like this, I don't get it.
They go away six months, year later, they're like, I should really try some rust again. So they try it again and they have no problems and they're like, I don't know what my deal was a while back. I like, I, I know I struggled with this and now I, it just makes sense and like, I don't know how to like skip people ahead in time that that six months or a year, but it definitely seems to be there's, and there's some people who will just, who just don't seem to ever get it.
I've definitely heard from those people and they do exist, but like, if you've tried rust and you struggle at it, just like give it a break and come back to it later. , um, it'll still be there and maybe you'll still hate it, but maybe you'll find it way easier. And that's just like a very strange phenomenon.
I I kind of, it's like when you go take a shower and you solve your problem and then you like rush outta the shower cause it's like, oh my God, I wasn't thinking about it now. It worked. Like, I feel like some people have like a six month long shower with rust where like it just rolls around in the back of their head and when they come back to it, it makes more sense.
So, um, yeah. So that's, that's some, some thoughts on that.
Justin: Definitely feel that. Uh, I think I had a, I had a, a slower start to begin with, but I, I'd had experience with c and c plus plus and I'm like interested in functional stuff and done a lot of scripting. So it's like, it wasn't too foreign when I started, but it was like a little bit of a learning curve. And then I like set it down for a little bit, came back to it and it was like, just worked for the most part.
And yeah, it's, it's been an interesting learning. Um, and there's been like a, a lot of really interesting development for me. So you mentioned, uh, command line applications. There's been like so many really, really cool c l I tools that I've picked up over the last few years, especially that just like replace my default stuff like, you know, replace CAT or LS or like whatever, like all these like default, like, uh, you know, it's like give me better ways to do these things.
And then, um, I think WAM is a really interesting use case. Uh, it seems like Rust has really been talked about a lot in the WASM community. Um, and just like seeing how that develops is pretty cool. And then, I mean, the other thing is like that. With any sort of like compiled language or you know, systems programming language or whatever you wanna say.
It's like there is like very obvious performance gains to using something like this, right? This is like, you know, when you set aside the garbage collector a and then, you know, you make some other choices. It's like there's some huge performance wins here. So if you're like wanting to handle like a lot of requests or whatever, if you're in the web world, then like, you know, something like this could help you do that.
Like, you know, use less system resources. So,
Steve: definitely. And it's not magic. I've actually seen naive node beat naive rust before. Uh, and that's due to a classic trap, which is forgetting the buffer, your io. Whereas node has like a bigger buffer by default. And rust has no buffer by default to someone to write the rust code and they write the node code and they'd be like, why is it so much faster?
And it's like, oh. Cause the node is executing like 1000th of the SIS calls that you're executing. So it's definitely not magic, but it can feel like magic because so often it is just faster even when you write basically the exact same code.
[00:42:13] Safety
Steve: One of the ways in which Rust gives you the ability to do these things is there's an escape hatch. So it doesn't turn off rust's checks, but it does give you some new tools that have no checks.
So those pointers you were talking about and see that caused you all that strife, you could use those in rust. But you have to specifically sort of annotate that section of code saying like, Hey, compiler, I'm about to do some stuff you can't know about, so you're just gonna have to trust me. Um, and what's nice is you can in, we can use a very common tool that program is used and that's encapsulation.
So you can build up a function or a data structure that uses this kind of like unsafe code internally, but presents an interface that is safe to use. And sort of what that means is that as a user, I don't have to care that you're doing some dirty stuff under the covers. Like I can just peacefully use your project and not have to think about it.
Um, but that also means that if there's a bug in that it could cause some serious problems. And so one of the things that's really nice about the dependency model, uh, that's similar to npm is that instead of me writing that unsafe code every time I. I install a package that has that unsafe code in it, and I use that.
And that means that we have more developers looking at the same implementation to find more bugs. And it also means that if one is found, we can fix it and update it, and everyone gets that benefit immediately. And so I also think that while it's like a good developer experience, it's familiar to a lot of developers, it also sort of helps sell the sort of cultural aspect that rust's trying to build around this.
Like let's build things that make it easier to do these low level tasks because. like, and to give you an idea of how low this like stuff goes, there's a package called X 86 and that package gives you the data structures that you need to like do the low level stuff on an X 86 processor. Like if the words like T l B or like, you know, interrupt handler or any of that stuff matter to you, like those str section definitions already exist and you just use them and they're right according to like the docs and like, sure, you could write that out by hand.
Then everyone who has written a hobby os has written those out by hand. But like, you don't have to do that menial, drudge work in rust. You can just install the package and get going for operating system development. Like, not, not even, you know, that's just like a wild thing that's not, uh, you know, the norm, uh, in many of these spaces.
So yeah,
Andrew: Yeah. Not to keep bringing it back to type script, but it's what I know, um, uh, the unsafe safe really reminds me of as any in type script, like being able to go, like, I love the type system, but right now fuck the type system. I know what my types are, don't care about. This little bit of code is so powerful.
Like I was helping my fiance's sister with c plus plus and we're just getting these like compiler errors was like, what is going on? Can we just at least run the program a little bit to see what's like, what's going on a little? And uh, just to have that escape hatch makes a typed language so much more approachable.
Steve: absolutely. And that's, it's also like rust does have, as you sort of mentioned, this very robust type system. But that's also important for its performance goals because again, on that trade off of like easy versus fast has historically been a trade off because easy meant like you don't have to really care about what's going on in fast meant.
You really have to care about what's going on. But the cool thing about types is because they check your code at compile time, they expend no time at runtime whatsoever. And so you can do stuff that like is checked but purely at compiled time and therefore you get these massive runtime efficiency gains.
By using this kind of stuff. So absolutely. Like it's very similar and also a very key, like part of how rust works.
Andrew: Yeah, I, I can literally already hear the arguments of the opposite side of that though. . Yeah.
Steve: There is. I think the, my favorite one is like, I can't turn Seg fault in a remote code execution, how am I supposed to jailbreak devices that are sold locked down? And so actually like, or like Rust will ruin the speed running community because if games aren't buggy anymore, there's gonna be no more bugs to exploit when trying to run video games as fast as possible.
And so I think both of those are very funny arguments. I don't think they're good reason for not, you know, improving software on this front. But you know, it takes all types
Justin: if software is a hackable, what are we gonna do with ourselves? Uh,
Steve: Yeah. Yeah.
[00:46:29] Oxide
Justin: Let's talk a little bit about oxide. Uh, I actually have not really mentioned it too much on the podcast. Uh, but yeah. So, uh, we both work at oxide. Uh, what do you, what do you spend your days doing at oxide?
Steve: Yeah, so if
Justin: Maybe we should talk about oxide, the
Steve: we say what it is? Yeah, yeah. So this is also, this is also relevant cuz it's like sort of, kind of what I'm doing. So, uh, anyway. Uh, so fundamentally oxide is the oxide computer company and it says very straightforwardly on the, the tin. What it is. Like you buy a computer from us, you give us money, and we give you the computer and everybody's happy.
Like that's the, the fundamentally of the business model. The kind of computer is the interesting part though. So we basically sell servers like you had put in a data center, but instead of them being like an individual u so if you've never used a server rack before, there's like, usually I think 42 is the standard size of a rack.
Uh, and u is, I think for unit, I don't know, I'm just gonna make that up and say that's true. I've never actually thought about that before. But you can sort of fit like 42 individual servers into a rack of servers in a data center somewhere. Um, and that's cool and good and it's worked for a lot of people for a long time.
But a lot of the bigger tech companies are building their own servers cuz like if you already know you're gonna build a data center, why are you building individual servers? Why not build a rack of servers at the same time and then fill your data server data center with the racks. And so they've sort of developed these strategies for building the hardware.
In a way that's like more conducive. The example that I always use is power. So like if you have 42 individual service in rack, uh, and you have a power supply in each one of them, you're being a lot less efficient than if you can put one big power supply for the whole rack and only do that conversion from AC DTC once, and then route the power to the appropriate places.
So you get this kind of like efficiency of scale by building a server rack as a whole cohesive thing as opposed to individual units. And so there's definitely a lot of folks from like a sun or apple heritage here. So you can kind of think of it as almost like an apple rack of servers. Like we sell you this appliance and it's all cohesively designed software and hardware together, and you get kind of the cloud experience of de deploying your applications.
But the, you get to own the hardware side. That. Um, and there's a lot of people, you know, cloud computing is good, but it's also a deployment model as well as an ownership model in a money sense. And we've sort of conflated those two things that like you have to rent to get the cloud deployment model. And there's some people who want to own servers, but also still want the advantages of the developer experience of a cloud model.
And so that's kind of like who oxides customers are to some degree. Um, so one of the things I've been doing a little bit more at Oxide lately, and I wanna sort of move into more so was marketing, which is why that's kind of a fun, uh, you know, let's, let's talk about that part first. But, um, what I started doing and what I'm doing right now is much more of the low level stuff.
So I kind of work on the, uh, the team that's sort of like an embedded team, I guess. We don't really have team names exactly at oxide, but like we work on the sort of like low level firmware stuff that is helping to build those servers in the rack. Um, and I started off by writing some code for that, but I've more moved into sort of a very much like a.
A sort of staff role where like I tend to work on the build system or things that are kind of adjacent to the folks that are doing the nuts and bolts, actual embedded development every day. Uh, and the current thing that I'm working on is improving compile times for the control plane implementation. So, uh, you know, our times aren't absurd yet, but every minute you can save, you know, if you save 10 other people one minute, every time they compile and they compile a hundred times a day, like you're meaningfully increasing focus's productivity.
So I've been investigating, uh, like how to drop the compile times on the, the control plane invitation lately, but that's kind of, uh, I do a lot of that stuff and helping, uh, with rust questions. One of our coworkers started a, a biweekly, one hour kind of like, let's talk about rust. Uh, meeting. And so folks will bring in whatever they're struggling with and I'll answer there.
We have a channel at work that's like rust questions. And so I answer questions there and kind of, sort of my jo my job is to like force multiply other folks at the company. And so whatever that ends up being, it's kind of a little fluid, um, which is how I like it. Uh, cause I get, I get very easily into things and distracted and onto a different things.
So it's nice to like have some freshness and variety in what I do.
Justin: Thank you,
Steve: Yeah. , you're
Justin: improving file binds is always, is always nice.
Steve: you could thank me once the patches actually land. Uh, I spent all last week doing the analysis and I'm like, here's the culprits of the mystery, but I haven't like, thrown them in jail or whatever. Whatever. This analogy's going like, I haven't succeeded yet. So, uh, you know, we'll get there, but, uh, yeah, totally.
Justin: Glad somebody's thinking about it. Yeah, yeah. No, it's, it's always an interesting transition about like, the things that are important and, and I think it's like, so I have this really novel position where I started my career in sort of like systems programming and a systems environment. And then I went more of the Javascripty web route, and then I'm sort of like, I'm still in the javascripty rope route, but I'm like, also, you know, like skirting the line a little bit.
And I, uh, it's, it's been interesting watching like the JavaScript ecosystem mature as rapidly as it has and like how they think about tooling and infrastructure and stuff. But I have a really profound, uh, both gratitude and respect for anybody who like, focuses on infrastructure cuz it really is like, It, it, it's a game changer for sure.
Steve: absolutely. I had a very similar background. Um, so because I became professionally known when I was working on Ruby and Rail stuff, a lot of people when they saw me go to Rust were like, oh, these dumb web people are trying to learn systems programming. I learned systems. I learned C 30 years ago. I started when I was seven.
Like I, I did, I did that stuff like a long time ago. And it doesn't mean I'm amazing at it. No, but like, I'm not some dumb web programmer. Like, not that I think web programmers are dumb, but like when people say that kind of stuff, like I also am not that person, even if you're trying to like, talk trash on those people.
Uh, so it's just like very funny, right? Like we forget that people can do different things at different points in their careers. Um, so yeah, absolutely.
[00:52:34] Tooltips
Justin: Awesome. Uh, shall we move to Tooltips?
Andrew: Want to hear the full interview in all of our tooltip. Head over to Patreon and subscribe.
Okay. That wraps it up for tooltip. Steve, thanks for coming on. Uh, as a JavaScript developer not . Knowing much about Rust, you did a really good job at explaining the community and all the tools, and I might even give it a try myself now
Steve: Thank you. I'm glad that, uh, glad it works. I hope you have a good time and if you don't, like I said, that's super okay. Not everybody has to love rust. It's totally fine.
Justin: Yeah. And likewise Steve. Thanks. Always a pleasure. Uh, and I'm glad to, uh, both share, uh, a little bit of like what we do with the wider world and I don't know, hopefully share the love of rust. So,
Steve: absolutely.