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.
know
This is how we dox ourselves.
Right, right, right, right. Uh-huh.
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.
Uh-huh.
So we could actually make allusions to things that are happening in the news without revealing how usually we're ahead of ourselves.
Oh, that's right.
We are.
We can. um
We have a Chicagoan Pope.
That's right. Chicago.
Yes.
We make popes. That's a shirt that I need to make.
We do. Da Pope.
Uh-huh.
I think that was the the Chicago Sun-Times headline was Da Pope, which will only make sense to people who are from Chicago or in America and have seen Saturday Night Live sketches.
Uh-huh. Yes. Yeah.
Right.
Yeah. You definitely don't have to be from Chicago to get that, but you have have to have seen the Saturday Night Live sketch.
but More into Right, as I mean, like no one in like my native side of the Atlantic will really know what the heck we're doing with that.
Mm-hmm. Nope. When do they ever though is the question.
Oh, ow. What passes for comedy in this country?
It's terrible. It's like that.
ah
You mean that joke I just made?
Yeah.
Yeah.
yeah Yeah. You mean "American makes slightly xenophobic gag?" Yes, that checks out.
Yes. Yeah.
ah Oh, this is not the direction we went to take this at all.
That's great.
Anyway, it's it's ah it's nice to see you, my friend. It's been a little while. um At least, you know, we we saw each other socially not all that long ago, but across a long table with lots of other people there.
Yeah, it has
So we haven't had a chance to hang out.
Mm hmm.
um But we we thought we'd take advantage, as I recall, of ah the fact that this is a timely podcast and actually talk about something which is timely. ah Which is a whole thing that blew up on the the HackerNewses and the the Reddits of like some old talk of mine.
Mm hmm.
And we should use it as a ah a topic of discussion because I think it it'll have some interesting, um you'll have an interesting take on it, I think. so So the talk that I gave was a few years ago and it was it was my first, I think, non-Compiler Explorer/performance sensitive talk.
Yeah, okay
It was just me saying, hey, I've been doing C++ a while and what I'm really, really bad at is ah programming. And so these are the safety nets that I make for myself. ah So in order to ah ah 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++ has some really powerful but wrong defaults that it kind of inherited mostly from C.
Uh-huh. Uh-huh.
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++ 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 like "how Matt Godbolt convinced me to move to rust", which was absolutely not the intention, but the the thesis was, this is just a reinforcement that C++ is a language 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?
Mm-hmm.
And so, first of all, that was not the intention of that talk.
Yeah.
And second of all, yeah, i don't know how well I don't know what to feel about that. It was it was an interesting moment. So what um what what are you what are your thoughts on like the you yeah this whole thing?
Mm-hmm.
Obviously, you don't program in either Rust, really, or C++ but you...
No, I mean, I i have, but I i ah 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 your how your audience is going to interpret that.
Ha ha ha ha.
And I think ah 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 in 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.
Very much.
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.
I'm sure.
And maybe that's on me and maybe that's on you.
I mean, I think this was um sort of willfully mis- differently interpreted, right?
Right.
You know, but it was an interesting thought, you know, like maybe that is, 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.
Right. Yeah.
And clearly it did for this person. It was like, screw this. I'm going to use a different programming language. Yeah.
Right. Yeah. Fear. Yes. Uh-huh. Yes. Fear with a hint of disdain. Those were the emotions that you managed to provoke in your in your observer in that instance.
in this observer. Yeah.
Yeah. Uh-huh.
Yeah. Have you ever had something like this before? You've, you've obviously written blog posts and things along the way and,
Yeah. You know, I mean, I have definitely had some things where um clearly I'm not getting the point across. And I'm 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 edge-cases 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, ah you know, this is why I kind of like, you know, we we joke about like consultant Ben and like the acronyms and, you know, CRUFT and FIRE and all of these other kinds of things.
Yep.
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. Um, cause if you don't, it's just so hard to communicate like the true nuance of the thing. Um, and so, you know, that's kind of like my, my hack for like trying to, 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.
You can, yeah.
Right. Right. 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, like that, 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'd never really kind of thought that there... obviously that's a didactic technique, right? For like, this is how I choose to present you're like, no, if I try and present something more complicated, at least to start with, then people aren't going to read, they going remember it.
Mm-hmm.
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? in this particular context, right? But at least you remember that the F means fast. So that's an important bit of the rest of, 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 want to stay away from. And I also and and I would be interested 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 I think there might be like a pattern of people like getting like repeating that and sort of like sort of like glomming on to 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.
but 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 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 ah functional style, very
Yeah. yeah
template heavy, very compile time heavy. And obviously the beauty of something like C++, such as it is, is that you can consider it a continuum. Even if you are more like, I'm just writing C,
with classes, very simple classes, you can say, yeah, but every now and then I'd write, where I would like to use a macro in C, 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 three or four kind of ways of writing C++ and ah and maybe that's not true in other languages.
I don't know. I mean, like we, we make the, the 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, and we joke about these things, you know factory get a set of things, right?
Yeah, right.
Whatever.
The factory builder bean. Yeah. Uh-huh.
Yeah. Yeah. Which obviously yeah I think Java has moved away from, and I know you're writing more Java these days than, than, than you were perhaps before.
Yeah. Mm-hmm.
*DOG BARKS* Sorry, sorry, editing Matt, you're gonna have to edit out a dog [EDITING MATT HERE! I couldn't be bothered!]. Yeah, so ah 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 enterprise-y bean factory stuff into a slightly more sensible ah subset.
Yeah.
um But then you think about like trading system Java, garbage-free Java, and that's like, oh yeah, that's it's a completely different sub-language, really, of of Java itself.
Yeah. Right. Yeah. That's a whole other variation. Yeah.
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 the same level of like, these two Java programmers just couldn't work in the same code base. Unless you've gone, you know, almost like the language forces you into it. Everything hit is OO, right? You're kind of stuck with OO because that's the way the whole language fits together.
Yeah. 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 a one of like you say, there's maybe four variations of sort of, you know, C++ plus plus ah archetypes.
Maybe, I think, yeah.
Let's just say it's four. It's like if that was true of Java, it wouldn't be that wouldn't be one of the four. Right. Like and and I'd be.
It's that, and and in in fairness to, again, specifically for Java or JVM languages, obviously you have Clojure and you have Kotlin.
Right. right
And if you want to do that kind of stuff, it's a different language and they interoperate fairly well. like So you just do that.
Yeah, pretty much seamlessly. And that would be and my exact point is like, this is just a Clojure 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. um So that's not like, that's not like a 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, you know, 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, yeah acceptable.
I think so. Yeah, absolutely. um ah Although, you know, yeah this is we're sort of off the track of where I was going with this, but it seems seems relevant. ah The presentation I gave a few weeks ago at the ACCU was me deliberately writing C++ plus plus in a way that I would never write it naturally, right? Myy particular kind of archetype is I am using sort of OO C++ with...
Mm-hmm.
Using templates for generic programming only, not for meta programming and not for like very complicated type related tricks.
Mm-hmm. Mm-hmm.
And certainly, 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 ah to to separate concerns. And I'm very thoughtful about how I try and separate the implementation from the interface so that I can do testing of the interfaces and the 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 here in the language.
Concepts, coroutines, constexpr, everything seems to begin begin with C. Consteval, I'm trying to think, there was one other thing, modules, which doesn't begin with C, but the C is silent in modules.
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 ah the podcast listenership will get the secret scoop behind it.
I was secretly hoping that I would write the code in this new-fangled way that I gut-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. Mm-hmm. Right. Mm-hmm.
Of course that didn't happen because nuance, right? This is it. Maybe this is the central theme of today's thing. isn't it 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.
Mm-hmm.
ah Anyway, I discovered that like I couldn't actually beat the performance of my first implementation [I meant the fancy implementation], I wrote the thing multiple times. so I wrote it once in ah my natural style. and Then I said, okay, now I'm going to take all the newfangled 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.
Yeah. Yeah, yeah, yeah.
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, h fourth way going, learning what everything that I'd learned from the 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 Yeah, yeah.
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 it, I suppose the story here is that the, don't let the archetype box you in and don't,
Don't pigeonhole yourself. Don't be afraid to try new things, I guess. That's what the talk's thesis was. But um as it regards to this particular thing, that the the archetypes ah are potentially, there is a benefit to picking one archetype over another, or one bit and it may be, say, performance.
Mm-hmm. Mm-hmm. Mm-hmm.
In this instance, it was perhaps, look, thee the ah the code base is slightly more ah coherent. No, what's the word? When i when things...
Cohesive.
Cohesive yeah overly cohesive right in terms of like this part no yeah couple thank you that's what again another C what everything needs to this episode was brought to you by the letter C
Coupled. Yeah. Cmodule?
And the number five.
Yes.
ah 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.
Yeah.
But I couldn't argue with the performance increase that I got. And for some applications, that's more important.
Yeah.
It probably wasn't for the one that I was doing, but it was it was noteworthy.
Yeah.
And I can now see why some archetypes might choose to go that way um because the importance of runtime performances trumps the ah the compile time or other aspects, right?
Yeah.
And for other people, it might be testability. I was only talking to somebody earlier this week about writing code in like very critical environments, like, you know, proving correctness in, you know, say automotive or aerospace or whatever like that.
Mm-hmm.
And at that point, maybe you have maybe got a real time constraint in 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.
Yeah.
So this is way off the original topic, but that's this, that's our podcast for you.
Yeah, well, there you go. Well, OK, so bringing this back to the to the sort of original thing of like the art 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 when When was that talk?
Yeah, just like maybe six, seven, eight years ago. it was pre-previous company, pre-crypto company as well. [Edit matt: it was July 2020] I think it was ah was at the first finance company then, yeah.
Yeah. And, and maybe I, maybe I lost the plot and it's like, but the, the talk that that talk was the comparison of these three different implementations or that was a, that was a different talk.
Yeah. no No, that was a different one.
Right?
That was another another one. Yeah. So what this one thesis was, you know, like the talk was called correct by construction.
Yeah. Yeah. Yeah.
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.
yeah right
So the one of the classic examples in that is without all of the warnings on, which you should just have on, there's no question of it, but like the default compiler will not warn if you, for example, take the example I gave is like placing an order on an exchange, send order. And you have "float" price, which you should never have. That's a whole other conversation, but like it suited my purposes, "float" price and "int" quantity.
Right. Yeah. Yeah.
right if you're trying to buy 100 google shares for a thousand dollars each you sure as heck don't want to switch those parameters and actually but you know buy a thousand shares for 100 or whatever sell would be worse in this instance 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
Right. Right.
because you can get it wrong. Why don't you make a Price class that has all the the things that prices need to do and a Quantity class that has all the things that quantities need to do.
Mm-hmm.
They are still just an int and a float or whatever. Again, don't use floats. um 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 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 chap was, Why you using a programming language, which even allowed that to happen in the first place?
Yeah.
It's great, because but 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 bools in a row as like parameters to a function?
Yeah.
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 solve that for you, or no language. That was just a bad API design. That's how I chose to... to, to, to expose, uh, uh, interpret this is bad API design. I think the take home for this blog post writer was like, why not make it impossible to make those APIs that bad. Now, again, bools notwithstanding, but yeah, go.
Yeah, you know, my my hot take reaction to this is going back to the Bjarne 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.
Zig.
Yeah, exactly.
Yeah. Zig or go or whatever is up and cool next.
Yeah, yeah, yeah. Because it's like, that's the thing is it's like sometimes this stuff is all just carpet bubbles, right?
Yeah.
It's like, oh, this is a problem that that affects us all.
What did you call that? Sorry, we're going to have to stop. Carpet.
Carpet bubbles, you know, you push the carpet bubble down and then it just pops up somewhere else and then you push it down there and then it pops up somewhere else.
Oh, yeah. No, I knew exactly what you meant when you said it, but I just never heard it called that before. I wonder if that's an American thing.
Yeah.
cut But yeah, whack-a-mole is what I would think of.
Whack-a-mole is the same thing. Yeah, yeah, yeah.
But yeah. like
um Where it's like you're just you fix one problem and you're just creating another one. or so Sometimes it's worse and you create two problems, right? And so like you it's it's really hard and it's really, really hard to look at that holistically.
Yeah.
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 you 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 ah researching this and writing it and then reading it, right? So it's hard, ah 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.
Mm-hmm.
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 which you think is best, because it's going to be very difficult to ah objectively say, well, X is better than Y.
Yeah. Yeah. I mean, there's, it is, it is, all those things are true, but it is absolutely unquestionable that the C++ has tons of own goals from the point of view of like, you know, things that it were we all wish it would be a different way.
Oh, yeah.
ah But it isn't. And of course, the superpower of C++ is that I can take code from 1988 that was written for CFront, Bjarne's original C++ to C converter compiler thing.
Right.
And that code almost well will almost certainly just work um in today's code. And that's great. and it But um unfortunately, it 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.
Mm-hmm.
And unless you scroll all the way to the top of the file that says you know "#pragma edition 2027" or whatever, you don't know whether or not it's safe to go int i without initializing it or not, because maybe in the old way it never...
Yeah.
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.
Mm-hmm.
Rust has essentially has had a more modern take on what all the defaults should be. And by and large, it seems we've got an awful lot right.
Mm-hmm.
um And there's no way in hell you're going to accidentally think that you're reading some Rust code and think it's C++ and go, oh, this is how it works. right No, there's no question. And nor are you going to include a C++ file from 20 years ago into your Rust thing and expect it to work.
Right.
It just doesn't.
Right, Right.
So the very thing that makes C++ powerful is also it's sort of undoing because we kind of can't solve that problem.
Right.
So yeah, nuance, it's subtle. Yeah. I mean, like right now, if I were to start a new project for 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 dont darn well like. um But ah yeah, i ah C++ is around for a long time because we use C++ to interact with the C++ we wrote last year and the year before that.
And our vendors wrote and the interop story is still not great in other languages.
Right. Yeah.
I don't think it's great in any language, honestly. I think C has become the standard interop for everything, which is a weird...
Right. That's the most universal one for sure.
Yeah, which which is to say, you know, only slightly above assembly language, which, you know, obviously warms 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.
Uh-oh.
Who knows? um But I think the value that reevaluating these things has is you get to learn from other people's experiences, aka mistakes, and say, ah 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 though the almost the worst case there is that you turn it into a carpet bubble. But probably what's going to happen is you're just going to 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, right.
And that is oftentimes what progress looks like. It's it's not like, hey, we eliminated all the problems. It's, we took all the like really terrible like you know buffer overflow problems, and we turned them into like sort of less terrible, OK, this just takes a really long time to compile, and it's hard to understand problem.
Right. Or, you know, Rust, how do i how do I find a way to explain to the borrow checker that this particular set of lifetimes is in fact okay?
Mm-hmm.
Or maybe it isn't.
Mm-hmm.
Or, you know, how do i ah yeah, how all of my ills about who is like who is meant to clean up this memory is solved by a garbage collector that has a different trade-off.
Yeah.
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.
Yeah.
You know, you can you can turn one problem, bad problem into two slightly less bad problems, or maybe you just trade off a thing completely.
Yeah, yeah.
Yeah. Runtime performance or, yeah.
Yeah. Interestingly, I was talking to a mutual Matt of ours the other day ah who had told me who was doing a lot of Rust and who had told me that he's like kind of given up on lifetimes.
Oh, cool. Yeah.
He's like, I'm just not going to use them anymore. I use them very sparingly now.
i thought 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 going to make it a phone call!
That is a very bad side effect of Rust. is it it's It's like a pharmaceutical commercial.
ah
"May lead to suicidal thoughts". No, the now he he has given up on using lifetimes and Rust because he's just like, there's just it's just too complicated.
Yeah, whoa.
I just don't do it anymore.
That's really interesting. So presumably... just essentially redesigning things so that you don't have to explain the lifetime of things to anybody.
Yeah. Yeah, it's just like, just make a copy.
You just, yeah.
Just make a copy. That's the easiest thing to do.
Right. Which is not a bad thing to do either. Yeah. i mean, and and again, that's another ah language, Val, which became some other name. I can't think now. and This is terrible. I should know all these off the top my head. "Hydro", something like that.
Right.
I don't know. youre i'm Dear listener, Ben is pulling all sorts of expressions of "I don't know" in the in the video chat.
I don't know. Yeah, no idea.
But that that was sort of founded around everything should be a value, ah which is very functional feely, right?
Mm-hmm.
And ah again, that that's another sort of like...
Mm-hmm.
a different direction you can go down. It's like, 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 lifetime began. So it's actually in this, it's still register eight. yeah.
There was no copy. We just carried on with it. Oh, it's that kind of stuff, which was always the way I felt about like functional languages where 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.
Right. Yeah. Right.
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
Right.
you know, careful.
Yeah, yeah, yeah.
And 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, the runtime.
Yeah. Yeah, yeah.
How did, 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. You're like, ah, now I'm out.
Yes, uh-huh.
Anyway. Yes. so You, you said about rounding it off. That seems like a decent, non-solution, non-description to finish, like any of our podcasts. But...
Yeah. Yeah, it's either this or we talk 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 extra spare time. um some Even though when I put them on like an 1.5x, which I'd be interested to know if anyone listens to this, especially when we're gabbling at full speed, anything other than 1x or 1.2x maybe. Yeah.
yeah. yeah
ah But yeah, we're not that long. And in fact, this is relatively short for us. So on that bombshell, maybe we should say, ah always lovely chatting with you, Ben. And I will see you next time.
Until next time.