Two's Complement - C++ and Rust: Different Tools for the Job

Episode Date: May 9, 2025

Matt and Ben discuss programming language debates sparked by an old talk that went viral. They explore how Matt's C++ safety tips convinced someone to switch to Rust instead. Matt stays up all night trying four different implementations to prove a point, then loses. Ben introduces the concept of "carpet bubbles" in language design. Matt lists all the C++ features that begin with C, while Ben questions whether Chicago makes popes.

I'm Matt Godbolt. And I'm Ben Reedy. And this is Tooth Compliment, a programming podcast. Good afternoon, Ben. Hello. Thus revealing to everyone the time of day that we record this. This is how we slowly leak information about our lives. This is how we dot ourselves.

Right, right, right. But it is indeed a beautiful, glorious spring afternoon. And in a rare departure from normal, we're going to record a podcast and then I'm going to release it in a few days time. So we could actually make allusions to things that are happening in the news without revealing how new you should know ahead of ourselves. We are. That's right. We can. We have a Chicago and Pope.

That's right. Chicago. We make popes. That's the shirt that I need to make. I think that was the Chicago sun times headline was dark, which will only make sense to people who are from Chicago or in America and have seen Saturday Night Live sketches. Right. Yeah. You definitely don't have to be from Chicago to get that, but you have to have seen the

Saturday Night Live. Right. As I mean, like no one in like my native side of the, the Atlantic will really know what the heck we're doing with that. But you know, When do they ever though is the question. Oh, well, you're what passes for comedy in this country. It's terrible. Like that.

You mean, yeah. Yeah. You mean American makes slightly xenophobic gag. Yes. Checks out. Oh, this is not the direction we went to take this at all. Anyway, it's nice to see you, my friend. It's been a little while.

At least, you know, we saw each other socially, not all that long ago, but across a long table with lots of other people there. So we haven't had a chance to hang out. But we thought we'd take advantage, as I recall, of the fact that this is a timely podcast. And actually talk about something which is timely, which is a whole thing that blew up on the Hacker Newses and the Reddits of some old talk of mine.

And we should use it as a topic of discussion because I think it'll have some interesting, you'll have an interesting take on it, I think. So, yeah, okay. So the talk that I gave was a few years ago and it was, it was my first, I think, non like compiler explorer stroke performance sensitive talk. It was just me saying, Hey, I've been doing C plus plus a while. And what I'm really, really bad at is programming. And so these are the safety nets that I make for myself. So in order to deal with my own ineptitude, I will do these things. And they were like,

you know, best practices, essentially best practices, you know, like, don't just use numbers, use types that wrap numbers and don't wrap them in the trivial way because often that has unintended side effects and all these things, right. And effectively all of them are amount to C plus plus has some really powerful but wrong defaults that it kind of inherited mostly from C. And if you go out of your way to write code this way, then you can kind of mostly negate the bad decisions that were made. And that's, I think how most C plus plus programmers survive is they ignore large swathes of the language and kind of go, let's just not do it that way. And we turn on all the warnings and the errors for things that you use that are

anachronistic and say, just don't do it that way. Um, the blog post that somebody wrote on the back of this, which was something And so, you know, I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point.

I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point.

I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. full of anachronistic bad things. And if you have to go this far out of your way to do it the right way, why not just use a language where the defaults are right? And so first of all, that was not the intention of that talk.

Uh, and second of all, yeah, I don't know how well I don't want to feel about that. It was, it was an interesting moment. So what's, um, what, what do you, what are your thoughts on like the, yeah, this self thing? Obviously you don't program in either rust really, or C plus plus, but no, I mean, I have, but I, uh, don't on a regular basis, but I think this is like the classic example of, um, as an artist, when you create something, you have no control over what you're, how your audience is going to interpret that. And I think, uh, one of the side effects of putting something on the internet is that people are

going to what you would say misinterpret, but is just internet interpret. Like they're going to consume it, they're going to process it, and then they're going to have some understanding of it. And how much that aligns with what was in your brain when you created it and what you maybe have had in your mind of like a theoretical consumer of this information that I'm creating might think these things. That's an illusion that you have as a creator of things

that that happens or will ever happen or can even happen. And so, you know, it doesn't really surprise me that much. I'm sure that you could find more of these of where you're like, you clearly didn't understand what I was trying to say at all. And maybe that's on me and maybe that's on you. I mean, I think this was sort of willfully mis differently interpreted, right? You know, but it was an interesting thought, you know, like maybe that is me. And, you know, it's interesting you describe it as art because certainly,

you know, I always think of art as some an expression that's designed to provoke or provokes an emotional reaction. And clearly it did for this person. It was like, screw this. I'm going to use a different programming language. Yeah, yes. Uh huh. Yes. Fear with a hint of disdain. Those were the emotions that you managed to provoke in your observer in that instance. Yeah. Yeah. Have you ever had something like this before? You've obviously written blog posts and things along the way. Yeah. I mean, I have definitely had some things where clearly I'm not getting the point across. And I'm always always torn and I bet you have this sort of same thing of like

There are so much there's so much nuance to this thing that i'm trying to communicate. There are so many Sort of like educations and interpretations And if I try to boil this down into something that a normal person would actually take the time to read They are almost certainly going to get it wrong and so Uh, you know, this is why I kind of like, we joke about like consultant Ben and like the acronyms and you know, cruft and fire and all of these other kinds of things.

But like, I feel like the key to these is like, you have to try to boil it down to something as simple as that and then just repeat it. Cause if you don't, it's just so hard to communicate like the true nuance of the thing. And so, you know, that's kind of like my my hack for like trying to do this and do it in a way that's sane is to say, you know, can I come up with the catchy acronym for it? Because that will help it also, you know, also stick in my brain. So when I'm

trying to explain it to people, I'm like explaining it in a consistent way. Yeah. But also in their brain to where it's like, you know, when I say fast, I mean, tests that run hundreds of tests per second, I don't mean like, yeah, we ran our whole test suite in 10 minutes, right? Like, right, if you had hundreds of thousands of tests, that would be fast. But that's not what I'm talking about, right? No, that's really interesting. Yeah, I never really kind of

thought that, that, you know, that obviously that's a didactic didactic technique, right? For like, you know, this is how I choose to present it, but you're like, no, I, if I try and present something more complicated, at least to start with, then people aren't going to read, they aren't going to remember it. So I'm just going to have to drum in this simple thing. And then I've got the bedrock of understanding, and then we can have a nuanced discussion about, well, is this, what does fast really mean, you know, in this simple thing. And then I've got the bedrock of understanding and then we can have a nuanced discussion about well, is this what does fast really mean, you

know, in this particular context, right? But you're actually remember that the F means fast. So that's an important bit of the rest of it. Yeah, yeah, yeah. Yeah, yeah, exactly. On the topic specifically of like Rust and c++, like, you know, I mean, my kind of, you know, very novice experiences with C++ have always been, there are just some areas of the language that you wanna stay away from.

And I also, and I would be interesting to hear your take on whether you think this is true, but my sort of perception of it is, is that there's not like really one type of C++ programmer out there. Like you very much sort of pick which parts of the language and what parts of the tool chain either fit you as an individual or maybe fit like your company or like the problem that you're trying to solve.

And you pull those parts out and you use those. And then I think there might be like a pattern of people like getting like repeating that and sort of like, sort of like glomming onto like that section of it. And so like, which is maybe something that is maybe less true of other languages, like you could take two people who call themselves C++ programmers and they will agree on nothing.

That is, that has definitely been my lived experience, you know, very much so. And certainly there is sort of nucleation point in a company where if you have one person who does C++ a certain way, you're either going to have a really hard time. If you hire someone who doesn't do C++ the same way as them, they're not going to work, be able to work together as well, or they're going to have to work in separate code base. Or you just start hiring people who all work right that way. And it's either, you know, very, uh, functional style, very template, heavy,

very compile times heavy. And obviously the, the beauty of something like C plus plus such as it is, is that you can consider it a continuum. Even if you are more like, I I'm just writing C with class is very simple classes. You can say, yeah, but every now and then I'd write where I would like to use a macro and see it is nicer to use a template to do the same trick. And you can borrow from opposite ends and extremes, but generally speaking, yes, there seems to be a three or four kind of ways of writing C plus plus and of,

and maybe that's not true in other languages. I don't know. I mean, like we, we make the, the best sort of example I can think of is, you of writing C++ and maybe that's not true in other languages. I don't know. I mean, like we make the best sort of example I can think of is, you know, like Java, you know, Java almost always seems to come across to me as very enterprise level. Everything's a factory, you know,

we joke about these things. Yeah, right. We get a set of things, right, whatever. The factory builder bean, yeah. Yeah, yeah, which obviously I think Java has moved away from it. I know you're writing more Java these days than, than, than you were perhaps before. Sorry.

Sorry, Matt, you're going to have to edit out a dog. Um, yeah. So, um, Java has got multiple like incarnations of Java, but I think by and large, most people that I'm aware of have moved away from the very, very enterprisey bean factory stuff into a slightly more sensible subset. But then you think about like trading system Java, garbage free Java, right? And that's like, oh, yeah, no, that's it's a completely different sub language really, of Java itself. So there is a little bit of that, but it's I don't think, and I'm not really qualified to say, but I don't think there is the same level of like these two Java programmers

just couldn't work in the same code base. Unless you're gone, you know, almost like the language forces you into it. Everything is OO, right? You're kind of stuck with OO because that's the way the whole language fits together. Yeah. Yeah. I will say that it's like I have seen people write purely functional Java, but it is weird. It is not like one of them. Like you say, there's maybe four variations of sort of, you know, C++. Maybe I think archetypes. Let's just say it's four. It's like, if that was true of Java, that wouldn't be one of the four, right? And and in fairness to again, specifically for, for Java or JVM languages, obviously you have closure and you have, right. And if you want to do that kind of stuff, it's a different language and they interoperate fairly well. Like, yeah, pretty much seamlessly.

And that would be, and my exact point is like, this is just a closure programmer that you forced to do Java and now they're doing everything as a function and with streams and everything else. Cause it's almost like malicious compliance at that point, right? So that's not like a way that I would normally expect people to use the language. Whereas it sounds like certainly that the case of in C++ it's like there are three or four different ways and you could reasonably argue about which way is better

or worse in different contexts, but they're all kind of like, acceptable. I think I think so. Yeah, absolutely. Although, you know, this is we're sort of off the track of where I was going with this, but it seems seems relevant. The presentation I gave a few weeks ago at the ACC you was me deliberately writing C++ in a way that I would never write it naturally, right? My particular kind of archetype is I am using sort of OOC++ with using templates for generic programming only, not for meta programming, and not for like very complicated type related tricks. And certainly, yeah, I guess that's the best way of me describing it. And, and I'm not afraid to use a virtual function here and there to, to, uh, to,

to separate concerns. And I'm very thoughtful about how, um, I try and separate the implementation from the interface so that I can do testing of the interfaces and compile time stuff. All right. We've talked about this kind of stuff before, but I'd force myself to say no, there's a whole bunch of new cool things coming in the language or or here in the language, concepts, co routines, const expert, everything seems to begin with C const eval. I'm trying to think there was one other thing modules, which doesn't begin with C, but the C is silent in

module. Yeah, right. Commodules. No, it's silent. But you got that wrong, honestly. But yeah, modules. And I tried to use all of these things to write a piece of code. And I was hoping, and now this is where the podcast listenership will get the secret scoop behind it. I was secretly hoping that I would write the code in this newfangled way that I got feeling don't like, and I would come away from it and it would be universally vindicating of my previous position that actually everything the way that I did

it was the right way. Right? Of course, that didn't happen because nuance, right? This is it. Maybe this is the central theme of today's thing is everything is nuanced. And there is no obvious one correct answer to anything. And even the archetypes sometimes move away from their archetype. Again, this blurriness around the edges, although, yeah. Anyway, I discovered that like, I couldn't actually beat the performance of my, my first implementation. I wrote the thing multiple times. So I wrote it once in a, my natural style.

Then, and I said, okay, now I'm going to take all the new fangled nonsense and I'm going to prove that this is both more complicated and worse. And unfortunately it wasn't that much more complicated and actually has some genuine benefits and the performance was considerably better. And then at the very, very end, like literally with a day to go before I presented it, I spent, I was up all night writing it a fourth way. I'd wrote it actually three ways, a fourth way going learning what everything that I'd learned from the cool new way, trying to

backport it to my original methodology. And it still wasn't actually any better. And so I was like, darn it. And this is a personal development journey more than anything else, which is kind of what the presentation is all about. But um, but yeah, I think it I suppose the story here is that the, don't let the archetype box you in and, um, don't pigeonhole yourself. Don't be afraid to try new things. I guess that's, that's what the talks, uh, uh, thesis was, but, um, as it regards to this particular, uh, thing that the, the archetypes, the archetypes are potentially there is a benefit to picking one archetype over another one bit and it may be say performance in this instance,

it was perhaps look, the the the code base is slightly more coherent. No, what's the word when I when things cohesive, cohesive, yeah, overly cohesive, right? In terms of like, this part? No. Yeah, coupled. Thank you. That's what I again, another see what everything is to this episode. Commodule was brought to you by the letter C. And the number five. Yes. No, so it was more everything seems a lot more coupled, which means compile times are higher. And you know, everything's more sensitive to change, but I couldn't argue with the performance increase that I got. And for some applications, that's more important. It probably wasn't the one that I was doing, but it was noteworthy. And I can now see why some archetypes might choose to go that way. Because the importance of runtime performances trumps the, the

compile time or the center or other aspects, right? And for other people, it might be testability. I was only talking to somebody earlier this week about, um, writing code in like very critical environments, like, or, or, you know, proving correctness in, you know, say automotive or aerospace or whatever like that. And at that point, maybe you have maybe got a real time constraint and performance, but more over than that, you have to absolutely be able to show that it's right. And that might inform the way that you write your code.

So, yeah, this is way off the original topic, but that's this, that's our podcast for you. Yeah. Well, there you go. Well, okay. So like, back to the, to the sort of original thing of like the art, the post that was going around about, you know, Matt convinced me to write Rust. So that was about a talk that you gave a while ago, right? Like when was that talk?

Maybe six, seven, eight years ago. It was pre previous company pre crypto company as well. I think it was at the first finance company then. Yeah. And, and maybe I, maybe I lost the plot and it's like, but the, the talk that that talk. Yep. Was the comparison of these three different implementations or that? No, that was a different one. Right. That was another, another one. Yeah. So what this one's thesis was, you know, like the talk was called correct by construction. And it was me saying like, Hey, if you write your code this way, then the compiler

won't compile your code. If you make a silly mistake, some of the many silly mistakes. So the one that a classic examples in that is, um, without all of the warnings on, which you should just have on, there's no question in it, but like the default compiler will not warn. If you, for example, take,, take the example I gave is like placing an order on an exchange, send order, send, send order. And you have float price, which you should never have. That's a whole other conversation, but like it suits my purposes,

float price and into quantity, right? If you're trying to buy a hundred Google shares for a thousand dollars each, you sure as heck don't want to switch those parameters and actually buy, you know, buy a thousand shares for a hundred or whatever sell would be worse. Right. Right. And the compiler will happily let you write that. And it won't give you a single warning because it says, Oh, this float can be exactly represented as an int. So that's fine.

And this integer is fine as a float. No question. You probably meant this, ha ha ha. And you're like, no, I absolutely never meant this. And so one example would be never accept naked ints and floats, because you can get it wrong. Why don't you make a price class that has all the things that prices need to do and a quantity class that has all the things that quantities need to do. They are still just an int and a float or whatever, again, don't use floats. But they are now domain specific objects that have useful functionality. And the compiler will tell you off if you switch them around. And then I present a whole bunch of like techniques and things to make that really straightforward and easy and even make it testable, all those kind of good things. And the take home from this chat was, why using a programming language, which even allowed that to happen in the first place is great because what you could forget to do this, or you could choose not to use this approach or,

you know, whatever. And it's the same with, you know, like the other classic example, which I don't think Rust has a solution is like, what if you have a, if you have a bad API design where you have five bulls in a row as like parameters to a function. It's like, you're just asking for somebody to screw the order of those things up. And there's no compiler in the world that will, will, will solve that for you or no language. That was just a bad API design. That's how I chose to, to, to, to expo, uh, interpret this is bad API design. I think the take home for this, this, this blog post writer was like, why not make it impossible to make those APIs that bad now again, fools not

withstanding, but yeah, go. Yeah. You know, my, my hot take reaction to this is going back to the yarn quote of like, well, maybe Rust just isn't used enough for people to complain about it yet to fracture into these three or four different archetypes, because people will have very strong opinions about, oh, you should always do it this way, or you should never do it that way. Give it time, my friend. And you too will be having someone write the blog post that says, so and so convinced me to never use rust and use whatever instead.

Yeah, exactly. ZIG or GO or whatever. Yeah, yeah, yeah. Because it's like, that's the thing is it's like, sometimes this stuff is all just carpet bubbles, right? It's like, oh, this is a problem that, that, uh, sorry, we're going to have to stop carpet bubbles. You know, you push the carpet bubble down and then it just pops up somewhere else. And then I knew exactly what you mean when you said it, but I just never heard it called that before. I wonder if the American thing, but whack a mole is what I would think of. But yeah, yeah, yeah. Where it's like you're just you fix one problem and you're just creating another one.

Or sometimes it's worse and you create two problems. right? And so like you, it's really, and it's really, really hard to look at that holistically and be like, okay, let's not, you wanna talk about things that won't hold people's attention. Let's not look at just this one problem in isolation. Let's look at all the universe of entire possible problems and consider at that level,

whether C++ or Rust is the right solution here. How many lifetimes do you want to spend researching this and writing it and then reading it, right? So it's hard, but I think that it's like time is the thing that makes that happen, right? Like time is the thing that sort of teases out like, okay, here are all of the edge cases of the edge cases of the edge cases.

And the only real way that you can figure this out is to figure it out for yourself. You got to go and dive into each of these things and learn them to a pretty deep level and then dive into the other things and learn them to a pretty deep level and then kind of just rely on your intuition to tell you what you think is best because it's going to be very difficult to objectively say, well, X is better than Y.

Yeah. Yeah. Yeah. Yeah. I mean, it is, it is all those things are true, but it is absolutely unquestionable that the C plus plus has tons of own goals from the point of view of like, you know, things that we all wish it would be a different way, but it isn't. And of course the super power of C plus++ is that I can take code from 1988 that was written, you know, with C front, you know, beyond as original C C++ to C converter compiler thing. And that code almost, well, we'll almost certainly just work in today's code. And that's great. And

it, but unfortunately means that all of the, the terrible decisions that were made back then propagate through time as well. And there have been some floated ideas about making like epochs and like, you know, scoping things with like, Hey, this is using the new semantics or whatever. But like the problem with that is the code still looks the same. And unless you scroll all the way to the top of the file, it says, you know, pragma edition, 2027 or whatever. You don't know whether or not it's safe to go into without initializing it or not, because

maybe in the old way it never, and so I get it. And this is why people want to say, well, let's just use just, I say, let's try using rust rust has, uh, essentially, uh, has had a more modern take on what all the default should be. And by and large, it seems to have got an awful lot, right? Um, and you, there's no way in hell you're going to accidentally think that you're reading some Rust code and think it's C plus plus and go, Oh, this is how it works, right?

No, there's no question. And nor are you going to include a C plus plus file from 20 years ago into your Rust thing and expect it to work. He just doesn't. Right. So the very thing that makes C plus plus powerful is also it's sort of undoing because we can't, it can't solve that problem. So yeah, nuance, it's subtle.

Um, I mean, like right now, if I were to start a new project for something, I probably would do it in rust myself for the same reason. I mean, partly because I have the flexibility now as I'm not doing anything else with my time to pick anything I don't darn well like. Um, but, uh, yeah, I, I, I, C plus plus is around for a long time because. We use C plus plus to interact with the C plus plus we wrote last year and the year before that, and our vendors wrote and the interop story is still not great in other languages.

Yeah. I don't think it's great in any language. Honestly, I think C has become the standard interop for everything. Right. There's a weird most universal one. Yeah, which is, which is to say, you know, only slightly above assembly language, which, you know, obviously warms my heart. Yeah.

Well, I mean, to, to maybe, maybe tie this off, I don't know if this is going to start a whole new branch of discussion or tie off the conversation. Who knows? But I think the value that reevaluating these things has is you get to learn from other people's experiences, AKA mistakes, and say, here's a mistake that we keep making over and over again, let's see if we can try to systematically solve it. And, you know, I feel like the, almost the worst case there is that you turn it

into a carpet bubble, but probably what's gonna happen is you're just gonna make it, one big bubble turned into a smaller bubble, Right? You traded one hard problem for another problem that was probably a little easier to manage. Right. And that is oftentimes what progress looks like. It's not like, hey, we eliminated all the problems. We took all the really terrible buffer overflow problems and we turned them into like sort of less terrible. Okay. This just takes a really long time to compile and it's hard to understand problem.

Right. Right. Or, you know, rust, how do I, how do I find a way to explain to the borough checker that this particular set of lifetimes is in fact, okay, maybe it isn't, or, you know, how do I, yeah, how all of my ills about who is a lot, who is meant to clean up this memory is solved by a garbage collector that has a different trade off. And so all these things, yeah, it feels like there's some kind of like, yeah, I think what you're saying, there's a sort of global minima that we're all in different little sub pockets of. And you can

perhaps find a lower minima somewhere else, but it's not that clear cut. You know, you can, you can return one problem, bad problem into two slightly less bad problems, or maybe just trade off a thing completely. Yeah. Runtime performance or yeah. Interestingly, I was talking to a mutual mad of ours, uh, the other day, uh, who had told me who's doing a lot of rust and who told me that he's like kind of given up on lifetimes. He's like, I'm just not gonna use them. I use them very, I'm so glad that

you said lifetimes when he said he's kind of given up on life. I was like, what? I'm gonna make a phone call. That is a very bad side effect of rust is it's like a pharmaceutical commercial may lead to suicidal thoughts. Um, no, no, he, he has given up on using lifetimes and Russ cause he's just like, they're just, it's just too complicated. I just, that's really interesting. So presumably just essentially redesigning things so that you don't have to explain the lifetime of things. Yeah.

It's just like, just make a copy. Just make a copy, right. Which is not a bad thing to do either. Yeah. I mean, again, that's another language, Val, which became some other name. I can't think now. Uh, this is terrible. I should know all these off the top of my head.

Hydro hide something like that. I don't know. You're a dear listener. Ben is putting all sorts of expressions of, I don't know. Yeah, no idea. The video chat, but that, that was sort of founded around everything should be a value, value, which is very functional feeling, right?

And again, that's another sort of like, different direction you can go down. So hey, everything's a value. And then you're like, well, but actually, it's too expensive to keep making copies of everything all the time. So somewhere, some clever piece of code, maybe in the compiler is kind of going, hey, we can actually use the same one, because we know that the previous lifetime actually ended and the new life that began. So it's actually in this, it's still register eight. So

there was no copy, we just carried on with it on stack kind of stuff, which was always the way I felt about like functional languages, but they're like, Hey, yes, if you want to, if you want to mutate a map, then you pass us the map and say, set key x to y, we return a new copy of the map with the exact same thing. And you're like, I don't, I can't believe it's an actual copy because that would never work. And they're like, yeah, but behind the scenes we're doing reference counting and we're doing, you know, careful. Then you're like, okay. So it's what you're saying is you're

faking this for pragmatic reasons. And so there is mutable state. It's just hiding inside the runtime. How did you write this mutable state in your functional language, which doesn't have mutable state? Ah, well, we wrote it in a different language. Anyway, yes. You said about rounding it off. That seems like a decent non solution, non description to finish on like any of our, our podcast. But yeah, it's either this or we talked for the next two hours and that seems unkind. That seems unkind. Yeah. I don't know. Actually, I mean, there are some long form podcasts out there. I've, as I've been discovering with all my extras, spare time,

some, even though when I put them on like an hour 1.5 X which I'd be interested to know if anyone listens to this especially when we're gambling at full speed anything other than you know 1 1 X 1.2 maybe but yeah we're not that long and in fact this is relatively short for us so on that bombshell maybe we should say always lovely chatting with you Ben and I will see you next time with you, Ben, and I will see you next time. Until next time. at twoscomplement at hackyderm.io. Our theme music is by Inverse Phase. Find out more at inversephase.com