Recently, a clip from Oxide and Friends was played by another podcast as something of a punching bag. Adam was called "uneducated" and Bryan, it was observed accurately, "hadn't used C++ since the '90s". Well, Conor Hoekstra from the ADSP pod joined us to settle the beef.
In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest Conor Hoekstra and Oxide colleague Cliff Biffle.
Creators & Guests
What is Oxide and Friends?
Oxide hosts a weekly Discord show where we discuss a wide range of topics: computer history, startups, Oxide hardware bringup, and other topics du jour. These are the recordings in podcast form.
Join us live (usually Mondays at 5pm PT) https://discord.gg/gcQxNHAKCB
Subscribe to our calendar: https://calendar.google.com/calendar/ical/c_318925f4185aa71c4524d0d6127f31058c9e21f29f017d48a0fca6f564969cd0%40group.calendar.google.com/public/basic.ics
Brian, welcome. Hey. Yeah. I was wondering, am I I realized that I
Speaker 2:had not
Speaker 1:actually ushered myself on stage Yeah. The reason that you were waiting for me to join because, it
Speaker 2:just thought, you know, we thought we'd wait for you.
Speaker 1:Sorry, Curtis.
Speaker 2:That's the end of ceremony.
Speaker 1:Yes. Kumar, how are you?
Speaker 3:I'm good. How are you doing?
Speaker 1:I'm doing well. It's good to good to hear your voice live.
Speaker 3:Yeah. It's nice nice to e meet you, Amber, and Adam as well, and this is gonna be fun.
Speaker 1:It's gonna be fun. So, actually, before we get started, so we had, Adam, we were we were off last week. We had, the open source firmware conference last week. Right. And, had a bunch of folks, up at Oxide on Tuesday night, and I gotta say, we had a lot of, fans of the pod, as they say.
Speaker 2:Oh, that's awesome.
Speaker 1:Oh. That's
Speaker 2:great. Yeah. It was pretty awesome. Do you sell some stickers?
Speaker 1:You know, I did. I got some tickets, but I gotta say, you know, a lot of people were, were asking after you. I to the point where I was, like, you know, but I but I'm here. And they're, like, yes. But where's Adam?
Speaker 1:Yeah. Fine. I know you you kinda said that earlier. Where's Adam, actually?
Speaker 2:That's that's great. I
Speaker 1:fully hear.
Speaker 2:That's that's great. I was just entertaining my folks, so, I I should have told them I I had somewhere else to be.
Speaker 1:Yeah. You will listen. Like, look. You're a nerd celebrity. You gotta get out and and, you know, be with your people.
Speaker 1:But it was great. Honestly, it was it was really great. It was a lot of fun to have, terrific conversations with folks that are loving the and and, Conner, I know you've gone through our back catalog just so we've gone through yours, and it's been, a lot of fun to to, be hearing from folks that we're having conversations that they're finding interesting. Just great. Because, of course, we find them delightful.
Speaker 1:So it's good. Glad you also enjoy it. And then we were in the so the the conference itself was, was down in Sunnyvale, at the Google campus. And, I was driving all the we had a a couple of Oxide folks out here, folks that have been on the podcast before. So, Laura Abbott, Cliff Beffel, and Matt Keter, were all giving and then Ben Saltz is also out here.
Speaker 1:The, but was staying down there. But so I was, shuttling all 4 of us down from the East Bay, and, we were, so we had we had some some long commutes. I mean, that's a that's a widowmaker Yeah. Commute from the That's right. Yeah.
Speaker 1:Just just brutal. And, I mean, it was much better when we got in the kind of the high occupancy way and so on. But we were it was actually a good week to do it because we were getting the play by play of the SPF trial. Are you how how are you paying attention to this thing at all?
Speaker 2:The I just just the teeniest bit that filters through on Twitter and other things like, apparently, Shakespeare, like, mathematically overrated.
Speaker 1:Oh my god. Oh my goodness. Yes. They did not. They they did not you know, I don't think they actually we heard them talking about that too much.
Speaker 1:Connor, have you been following this closely, this SSPF trial?
Speaker 3:I do not. I see every once in a while a YouTube video that recaps the drama, but, no. I I mean, I know the the high level details, but have not been followed.
Speaker 1:I mean, it feels like you're judging us, those who live in the sewer. Are you am I am I sure enough to read that in? Like, look. Look. We need our we we need our our drama.
Speaker 1:Okay? We need we we need our soap opera. And so and do you wanna explain with you the the the Shakespeare references? Because that would that was I mean, there's a lot that bonkers about this thing.
Speaker 2:I'll try. So this was SBF basically saying that, you know, statistically, because so many people have lived since Shakespeare, that there's no way that Shakespeare could have been the greatest author of all time because surely, like, 1,000,000,000 and 1,000,000,000 of people have lived since. And one of them must be the greatest authors of all time. And leaning that logic on Bayes, which many hasten to point out, had lived kind of a long time ago.
Speaker 1:I I kinda love this idea of Adam Leventhal reads your least favorite SPF positions. And just like it's it's kind of listening to you squirm about a position that, like, I'd see I ardently disagree with literally everything about this, but you're making me repeat it. So how do I do this?
Speaker 2:How do I hold this up with as few fingers as possible?
Speaker 1:As few fingers as possible. Totally unhinged. First of all, it's like in response to the greatest straw man of all time, like, who who's he in an argument with?
Speaker 2:Who's like
Speaker 1:I it's it was so unbelievably and also for a person who's like a master of probabilities, he did you see the other one about, like, if there was a coin that you could flip, and there was a with a 50% odds that that the world will be annihilated, and a 50%, 50% chance that that that everyone's happiness will be doubled, he would enthusiastically flip the coin. And apparently, at least what, what what Matt was saying is, like, no. He would enthusiastically keep flipping the coin. What? But so it was it we we work in the play by play.
Speaker 1:It is it is jaw dropping. Matt had another great line, which is like, I just wanna live my life such that my chats are never entered into evidence because they they sound like such absolute idiots. They I mean, and they are at some, like, some real level. They are kind of all idiots, but, they really sound like it. And the so the the podcast I'd recommend on this, which is not one that I would normally listen to, but it's a crypto podcast, which is like, boy, am I I'm I'm I'm in.
Speaker 2:Okay.
Speaker 1:Yeah. I know. Right? Exactly. So this is Unchained with Laura Shin, and she's got she's got some very, very good reportage on this, and is really and, actually, I love she's been basically reading elements of the transcript.
Speaker 1:She's got some commentary on there that's incredibly good. She has these 2 attorneys that that on there as regulars. I don't know if this is bothered to use with that. One of them pronounces Alameda Research as Alameda Research. Have you heard Alameda?
Speaker 1:People will say Alameda because Al you see Alameda as
Speaker 2:I live in Alameda. I've definitely heard Alameda or lots of variance there.
Speaker 1:Right. So this is so and, I mean, Adam, you live on you you and I both live in the county of Alameda. You live on on the island of Alameda. I mean, it's like there there's a lot of we got a lot of Alameda's in our lives. And it's That's right.
Speaker 1:Folks, it's not Alameda, please.
Speaker 2:Well, I will I will share because you mentioned that for, like, the early days of, of, like, the SPF unfolding of of the exchange of FTX and so forth, I was like, the there's that woman who was, you know, the president of, Alameda Research. And I was like, wait a minute. She's not our mayor. What's going on here? As I kind of barely paid attention to this and got confused.
Speaker 1:You got confused between the president of Alameda Research and the
Speaker 2:Oh, just like I didn't realize Alameda Research had anything to do with FDX. I was just like, I I just stopped at Alameda, I guess. Right. Because I'm such a Alameda Homer.
Speaker 1:Right. Exactly. I know. And people pointing out this may be the original Portuguese pronunciation. So, you know, it did I did actually wonder, and, Adam, it did remind me of your Gelsinger chassis on premise on premise with Supercut in that
Speaker 2:Yeah.
Speaker 1:Laura is very clearly saying alameda over and over to him, and he is saying back alameda over and over to her. So it's like, you are each clearly aware of the others. So I don't maybe we're pronouncing it wrong. Maybe we do live in Alameda County. Maybe we've been wrong all along.
Speaker 1:Connor, one of the things we've definitely learned in this podcast is that we mispronounce everything. I mispronounce. I guess I should I should really make this much more specific.
Speaker 2:Oh, and I just avoid any word that I'm not sure of. So, I mean, who who is really the fool here? Right.
Speaker 1:Right. One of us is a chicken, the other the other is jackass. You get to pick who's who's who's who's who's here. Anyway, so that was fun. That was that was a it was a a fun week, and, I think a lot about the podcast.
Speaker 1:But it's so that is not why we're here. We are not here to talk about SPF. We are here to settle beef. We are here because so, Connor, I was out at Mugtoberfest, which and, Adam, you've never been to Moktoberfest. Right?
Speaker 1:This
Speaker 2:year has been on Almost went this year, but had to cancel again because the aforementioned visit for my folks.
Speaker 1:Yes. And the, great conference. Obviously, I'm very grateful to Steven O'Grady, and his crew there at Broadmunk. They do a terrific job and have a bunch of talks that that we don't necessarily see anywhere else, which I'm very grateful for. And I've had I've been privileged to speak there a couple of times.
Speaker 1:I'm really excited to get the, I I have a talk on, on the the humanity and engineering. So trying to to, quell some of the fears about the, the AI singularity. So looking forward to that video coming up. But it was on the way back that I listened to this podcast, and, this is the, Algorithms Plus Data Structures Equals Programs podcast. Connor, this is your podcast.
Speaker 3:Yep.
Speaker 1:Which which I've definitely listened to from time to time, and I I I have definitely enjoyed. And I came across the transom, and I we were, we were getting called out a little bit. A little bit of little bit of podcast beef, which I have to say, Connor, we were delighted by just, like, just to set the stage. We really enjoyed it. And we know that you and I just follow you online and know that you're a a big fan of podcast.
Speaker 1:So, Connor, I thought if if you don't mind, I thought we might start with the the thing that we said that you were quoting back to your cohost, Bryce. Is that a fair place to start?
Speaker 3:Sounds good.
Speaker 1:Alright. So we are gonna start Adam, is that, the
Speaker 2:Absolutely. This is using soundboard technology, which we have never tried before. So let's give it a shot. Let's give it a shot.
Speaker 1:So this is Beautiful c plus plus is to you is just like, this is why we should have Rustic. This is not It's
Speaker 2:I mean, it it is it is a I I'd actually recommend it.
Speaker 3:Like, I
Speaker 1:I think it's an interesting book. I no. No. Are they gonna put that on the back jacket? I'd I'd I'd actually recommend it.
Speaker 1:Raves, Adam Levittall.
Speaker 2:I I I did I do wanna, like, see if I can get so the the authors are Guy Davidson and Kate Gregory. And I would be very interested to see and I I've looked all over to see if they acknowledge Rust. And the closest I could find on Twitter was Guy Davidson saying, I don't really have time to try new languages. Which is which is such a shame.
Speaker 1:Yeah. Yeah.
Speaker 2:That's Because these are these are folks who who really have nuanced deep thinking on on this, you know, very important language. This is not the disparity of c plus plus but one that they they are themselves ready to acknowledge the burs and the mistakes of. And, you know, I'd love to see what they think of Rust just because I feel like, seriously, like, every page is just more and more of an advertisement for it. And then when you get into, like, concepts, like, concept concept is a concept in
Speaker 1:c plus plus. And, yes, I had not. What there's a thing called concepts?
Speaker 2:There's a thing called concepts that is a a bit like a trait. K. But people are gonna like big pillar in there for for making that kind of, like, gross and, analogy there. But it it, you know, it's, it's for describing the characteristics of a template. You know, the the type t needs to obey these these parameters.
Speaker 4:Okay. Alright. I I really I gotta say, people like this are the reason that that that people dislike Rust.
Speaker 2:Alright.
Speaker 4:And not like on a technical level.
Speaker 3:What do you mean people dislike Rust? It's the number one most loved language in the
Speaker 4:Right. Right. But the
Speaker 1:Alright. That's the so, Connor, first of all, I we loved your I would. Actually, first of all first of all, if you had told me that, like, there's a clip from the show about c plus plus that people are going to, run with, This I feel is you took one of our most gentle assessments of c plus plus I feel like we've said much worse about c plus plus.
Speaker 3:I'm aware. I'm aware.
Speaker 1:You know, and I gotta say, I think thank you for not pointing out to your cohost being like, oh, by the way, like, sorry. Do you want me to get, like, the actual deep cuts on c plus plus? Like, they've said all sorts of like, there's no analog in here to substance abuse, to, to to, teenage sexual behavior, to when out of one of the other things we've used as a metaphor for c plus plus. I feel like there's all sorts of things that we've used.
Speaker 2:Yeah. Yeah. Definitely, like, drug use, like, with, with your child or whatever. And and certainly when I think, Brian, you DM'd me, like, oh, that one of our shitty hot takes was the subject of another podcast. This felt like we got lucky.
Speaker 1:Great. Well So kinda yeah. With so tell us about, like, that clip and how kinda how it spoke to you, and, they can kinda take it from there.
Speaker 3:I mean, this is gonna sound absurd, but yes, I have a habit of the podcast that I I listen to, you know, 70 plus podcasts. I'm a huge podcast fan and I have a short, I have a short list. I listen to these all at like 2.3 times speed. And so and, I spend a lot of time, running around, like, for exercise. So huge podcast fan, but I was actually listening, and and and Oxide and Friends, I wish way more companies, like, a huge kudos to to both of you and all of the folks in the past that have, you know, spoke up on these.
Speaker 3:There are very few podcasts like this. And I mean, I just
Speaker 1:Yeah. I it feels like this is, like, super light lift.
Speaker 3:I mean, so I mean, part of the goal well, we're going on a tangent here. So we'll we'll get back to how I I came to splicing that clip in. But, you know, Sean Parent, who I'm not sure if either of you are familiar with, but is a a luminary I mean, I guess, you listened to the Sean Parent episode, which was delightful.
Speaker 1:Yeah. Amazing. Yeah. We'll, we'll we'll drop a link to this, but this and you had Sean Parent a couple of times. But Yeah.
Speaker 1:Yeah. At the particular episode that I think Adam and I both listened to was this absolutely nutty story of a car crash that he was in. And I've read I mean, I'm not gonna I I'm not gonna give any more context within that. I thought it's an amazing story that definitely captures, like, a moment in history in computing history, honestly.
Speaker 3:Yeah. But, so he, you know, I've I've looked up to Sean and, I'm happy, like, to be able to call him a friend these days. But back in 2017, 2018 to like to me, he was just a person that I had seen his talks online. And once I had gotten to meet him, I asked him, you know, how come you don't start a podcast? Like there are not I think you used the word, you know, seasoned in your social audio talk, Brian, like seasoned folks that have experience, you know, there's too many, no offense to everyone with a podcast, like myself included, like, you know, I was born in the nineties.
Speaker 3:Like there's too many young people, you know, putting out their thoughts and opinions and not enough folks with, like, real experience and decades of war stories or, you know, choose the better word for war stories. And I asked him, like, how come you don't start a podcast? And he just I think a lot of those folks aren't interested. And he said, if you start a podcast, I will be happy to come on, like, however often or frequent that you want me to. And so Sure.
Speaker 3:Yeah.
Speaker 1:We can do that. And so
Speaker 3:we've had him on, I think, 4 or 5 different times, and we usually slice and dice them up. And, like, most recently, we were at a conference in Folkestone UK in, June at a c plus plus conference. And, like, over wine in, like, an hour and a half, we, like, got to talk to him about, you know, how he ended up at Adobe when he was at, you know, Apple before, where he likes to say, like, in between jobs. And and he you know, I think you've referred, Brian to folks that have this just, like, amazing storytelling capabilities, but then also, like, amazing stories to go with that. And Sean is one of these people, and it's just it's a blast.
Speaker 3:Anyway, so why more folks don't do it? I think it's just it's work and, a lot of these folks aren't interested in, you know, trying to set that up. But, like, I think the key is it's like if you're interested in having those conversations, you'd be surprised how willing some of these folks are to, you know, do the storytelling part as long as they don't need to do any of the work of it. Yeah, I'm not sure if you want to add anything on your thoughts on why more people don't do this.
Speaker 1:It's a great point, and you and we definitely had that feeling with on the metal where we had, you know, these kind of, folks giving us unbelievable stories and, excited to do it, excited to to kind of volunteer their time to do it. So and I would also say for whatever it's worth, I think it's great to get, folks in the nineties born in the nineties too. I think it's I I love getting all those different perspectives, and I I I do and kinda, I'm not sure if you saw I keep a talk on on social audio and kind of what the social audio as a vector for engineering wisdom based on our experience with Oxide and Friends, that that if you haven't seen, would definitely resonate with you. But the, I I I do actually I would love more folks to do this, and if you do, like, let us know. And Connor, I guess, I I I also wanna go back to 70 podcasts.
Speaker 1:Are you a you were a regular listener of 70 different podcasts?
Speaker 3:Yeah. I mean, subtract maybe, like, 15 of those that, like, don't actively post. Sure. So it it's not. But, like, in I counted in my app, a few days ago because I'm always curious.
Speaker 3:And and yeah. Yeah. I just
Speaker 1:I think
Speaker 3:it's people underestimate, like, the utility. And like I did watch your social audio talk. You recommended Oh, yeah. Yeah. And I would have, I mean, I thought it was fantastic preaching to the choir.
Speaker 3:The only thing I would say is like it's, it would have had like a catchier title with like the power of podcasting or something like that. So but, yeah. I wish I wish more people would do it
Speaker 1:and, like Is is is these whippersnappers trying to trying to, gen z up my title. I don't know.
Speaker 3:Spicing up that. Yeah. It's it's unfortunate. Like, on YouTube, the number the two things that, affect how well a talk does or like a video does, like number 1 is thumbnail and number 2 is title. Like, you'd think that the content matters most, but like that's number 3 after those 2, which is I don't know.
Speaker 3:It is what it is.
Speaker 1:I'm gonna have to bring you in as a as a title consultant.
Speaker 3:Sure. And then I'll get into that.
Speaker 1:I will need to run it by my kids to see if it's if it's actually if it's actually cringey or not. My teenagers who are, who who serve as a Gen z slang check for me. Make sure that I'm not being I wanna, you know, I wanna say things are lit out, and I'm told that, like,
Speaker 3:no dad can use it.
Speaker 1:It just sounds ridiculous. Please don't. Also, I do TikTok
Speaker 3:once where kids were were some young that that was, like, Gen z talk, and I didn't understand at all what was what was said. And, like, I was just like, wow. I guess I'm old now because this this this speak that they are speaking, is foreign to me.
Speaker 1:Well, so I do have to say yeah. I mean, this is where Adam and I do have an advantage. On the one hand, we are are are older, and this is not our generation. On the other hand, Adam and I both have teenagers. So we actually, are a bit Rosetta
Speaker 2:Stone. Yeah.
Speaker 1:Rosetta Stone. And I there is some Gen z slang that is delightful. Adam, the the the, the 2 that I think are just terrific are, 1, mid. As do you use mid? I think mid is is terrific.
Speaker 2:I don't know mid.
Speaker 1:Oh, I actually looked that up.
Speaker 3:That was in the video, and I I urban dictionary that,
Speaker 1:Yeah. A mid is and you didn't mid is what you would expect it to be. Like, if I said, like, you know, how how is that burrito? It's like it's mid. Uh-huh.
Speaker 1:It's like Gotcha. Yeah.
Speaker 2:The other one's gotta be Rizzy. Rizzy's gotta be the other one.
Speaker 1:Is Riz. The other one is I think I I think Riz and Riz to me is serves as, like, a testament to the English language about how then Gen z uses it. It's, like, all parts of speech. And, the and I actually I came across this when, I when one of my when my son and one of his friends was looking at at his father, and we are at, you know, an event where he is talking to to 2 other women parents, and he said, look at that guy, the Rizzler. I'm like, what's the Rizzler?
Speaker 1:What is the what is the Rizzler? But anyway, Rizz is is terrific.
Speaker 3:My understanding of the word mid is actually or according to what I Googled was that mid is actually, like a very bad insult because it's you would rather be at the extremes, like the best or the worst because, like, that'll track online. Whereas mid, it's actually like you're just in the middle of the bell curve and, like, no one's going to care. So, like, you'd rather actually be, like, really bad than mid, which is confusing to me. But, hey, you know, kids these days.
Speaker 1:Yeah. So, I mean, actually, my criticism of GPT from a writing perspective is its writing is mid. That is actually the problem with GPT is I mean, almost analogically is that it's that it's mid. So, but, yeah, I kinda I'm gonna have to I'll I'll consult you, but then I'll I'll I I hear what you're saying, that the the the titles simply do not do not, are too descriptive. I'm not you know, it it is it reminds me of of the criticism we heard from the original oxide pitch deck, which is, like, this is very good, but it's full of words.
Speaker 1:I'm like, it's okay. Yes. It is. Yeah. I mean, there's yes.
Speaker 2:Well, to be clear, as opposed to there being any pictures?
Speaker 1:Well, okay. No. There are they but there there are words. There are word. I I'm just like look.
Speaker 1:I'm I'm like, I'm pro literacy. I'm just I'm wrong literacy.
Speaker 2:There you go.
Speaker 1:And, yeah, it's the their words. Maybe not so many pictures, but but definitely words. So yeah. So, Connor, you so you listen to a ton of podcasts, and I I we I guess I'll look to you then as a as a, like, an early barometer for some of the ones that are particularly stand out to you, because I would love for a bunch of others to be like like us and like you in kinda capturing these narratives from technologists. And you've got you've gotten a lot of them.
Speaker 1:You've got a lot of different folks, on on ADSP. It's pretty awesome.
Speaker 3:Yeah. I mean so, yeah. We'll second tangent, and we'll get back to, you know, when I was listening to that episode. But I mean, I think it's very individual. I'm a huge programming language enthusiast, like my favorite languages.
Speaker 3:Over time. You know, at one point it was Haskell. In the last 4 years, it's all been array languages of which I think the very first time I came across your name, Brian, was not a talk. It was actually the article where, the art articleification of your interview with Arthur Whitney, who is
Speaker 1:Arthur Whitney? Yeah. I I yeah. I wondered if you'd seen that, because you you had a podcast you're talking about, q and k. Yeah?
Speaker 3:My second podcast, a Raycast, has been going on for 3 years now, 60 episodes, and it's all about, APL and other array languages like JKQ, BQN, very recently a language that just came out in the last couple of weeks, WEEWA, that's UIUA, which is super interesting. It's a symbolic language like APL that combines a stack from, like, concatenative languages like Factor, Forth and Joy and sort of the APL array paradigm. That's a whole other episode topic. But so I love the programming language episodes for sure. Especially the drama ones.
Speaker 3:Like I think recently or in the last couple of months when the Rust, you know, leadership stuff was going on and open source stuff. Like, you've had a couple different episodes where you brought folks on. And I I just love that intersection of, you know, drama and, the the the inner workings or inside baseball of that stuff. I also love all of the books episodes that you I mean, this was one of them, where you go through different books And, I haven't actually read, the next book with Steve Jobs, but I have, like, a bunch in my audiobooks, or Audible account and on my list to read. And, especially like just the history ones where you're talking about your time at Sun Microsystems.
Speaker 3:Like that's the stuff that's, in my opinion, like going to be forgotten in the annals of time if, if it doesn't get recorded on a podcast. Which is why I think it's, it's so like valuable to I mean, there is a YouTube channel called oral oral computer history but like those are pretty,
Speaker 1:pretty dry. Computer history museum. Computer history museum are amazing. Yeah.
Speaker 3:And those those are like 3 hours in length and YouTube videos. And so I haven't watched a lot, but, yeah, like, I think that kind of stuff. But you you the way it's packaged here, it's more, you know, interactive with folks in the crowd, and it's just, I think, more, entertaining. Whereas I've listened to some of the oral ones, and and they're definitely not. It's just a back and forth kind of, you know, storytelling.
Speaker 3:Anyway, so, yeah, the the book ones, the history ones, the programming language ones, those are probably, at the top of my my favorites.
Speaker 1:Yeah. That's awesome. I'm really glad that you liked that. I mean, I think, Adam, you and I both love books episodes in part because I we come out of every single one of those with, like, a really interesting cue, and then it's great to go, like, read some of those books and and kinda come back for more. I mean, I I that's been I'm glad that you like this, Connor.
Speaker 1:I've been, it's those have been really, really fun to do, and to learn. I I again, I've learned, like I I've also learned that I will basically, take whatever whatever Ian is is reading. I will basically you could just, like, move that key right on over to me. The the I but there've been some great recommendations on that. It's great.
Speaker 3:Yeah. Speaking of which, this is a great way to circle back to. So I was in Vietnam for a wedding in September and was inand this gets back to how I was listening to this. I was in Thailand before I was in Vietnam. And without going into detail, a very, I'm an obsessive podcast listener, but also an obsessive runner.
Speaker 3:And I was actually wasn't on a run. I was on a walk because I had run that morning and I was just walking randomly next to this highway because there's a website that I'm addicted to right now called citystrides.com that, like, tracks your completion of streets wherever you go, and you get, like, ranked on a global leaderboard. And so, if I'm ever, you know, have some free time and I'm in a new city, I just wanna go walk around and, like, collect nodes to, like, increase my ranking. And so here I am walking on the side of this, like, highway to get to this really dense cluster of streets. And I'm going through I'm like, my podcast queue of new episodes is empty, and I'm going through the backlog.
Speaker 3:And, you know, I am expecting a great episode because I love these books, Juan, but then boom, like, sure enough, in the first 10 minutes, you're talking about a book that, both my co host Bryce and I have talked about before. And Kate Gregory, one of the co authors we've had on as a guest, and she actually lives just outside of Toronto, Canada, which is where I currently live. And she's involved in running the CPP North, C plus plus conference that's happened for the last 2 years. So, like, Kate and I know each other very well. And and anyway, so it's just like the the colliding of worlds, and it's on top of a lot of, discussion around successor initiatives and language languages such as, you know, Carbon out of Google, CPP Front or CPP 2 out of not really Microsoft, but Herb Sutter, who is the chair of the ISO committee.
Speaker 3:There's HILO out of which was formerly named Val out of, Adobe. There's a a next generation, you know, bleeding edge compiler called Circle out of 1 individual by the name of Sean Baxter who's in New York. So there's all this stuff happening around. And then you can add Rust as, you know, contributing to the discussion of, you know, is c plus plus, you know, has it had its peak and it's now sunsetting or is it gonna go through a winter and, you know, the 20 aughts or whatever up until 2011 was kind of a dark period for C plus plus And there's a so a lot of discussion that's been happening over the last year. And I just finished listening to a CPP cast episode where they were talking about sort of some of the work on the next big language features it had been stalling in the committee.
Speaker 3:And so, you know, I I'd heard that clip and was like, oh, that's not great. And then I heard this episode, which technically is from, you know, the history, you know, the backlog. And I was just I had the biggest grin. I think I was even laughing while you guys were like that that there's the the 2 bits where I knew I was gonna cut in where one, it it was the it's basically just an advertisement for Russ, this book. And, you know, people in the c plus plus community are saying, you know, oh, this is a great book.
Speaker 3:It's actually, what it does is it takes 30 of these guidelines that are recommended in what are called the modern c plus plus core guidelines that sort of came out of Microsoft, but it's an open source thing that people contribute. So it's this, you know, k. We have all these modern features, but here's some best practices that you should adhere to. And so they took 30 of those and bookified it and basically added added examples. But it's it's completely You
Speaker 1:have effective c plus plus then. Scott Myers' book.
Speaker 3:Yeah. Yeah. I mean, there was 4 or 5 of those, and those were I mean I mean, he has famously said that the fact that he those books exist are are like a stain on C plus plus history. Like a good language shouldn't need a book telling you like, oh, here's how to, you know, avoid this anti pattern. And, you know, we just introduced, you know, universal references or forwarding references and, you know, here's all the the pitfalls with these and how to avoid them.
Speaker 3:Like, I've never talked to Scott personally but I've heard him on interviews saying that, like, I would prefer if I didn't have to write these books. Like it's sash Yeah.
Speaker 1:Have you ever seen Scott speak, Adam? Or do you
Speaker 2:No. Never.
Speaker 1:So you he you we share an alma mater with him. He was getting his PhD. Yeah. He was he had just finished his PhD at Brown when I was an undergrad. And, I if memory serves, and so he, and he's very funny.
Speaker 1:In particular, what I definitely remember on him is he had a Pascal rant. And, Connor, I I hate to do this to you, but Pascal. Pascal. Please. Now the the
Speaker 2:We mentioned the pronunciations earlier. Pascal?
Speaker 1:It is really not Pascal. I I I just listening to the most recent, the ADSP where I because I I I feel like you were going into that conversation saying Pascal, and then you were, like, changing to Pascal over the you reminded of, like, my wife is is from Brazil, and then when she she when she would talk to her mom, she would, like, her accent would become, like, more Kiwi, and I feel like you were you were, and so, yeah, I I would I think we say Pascal. But I have
Speaker 3:the same problem with Java and Java. Like, I think I switch between the 2 when I'm talking about
Speaker 2:Well, that's a north of the border thing.
Speaker 1:I mean, that's Yeah. Isn't that a cultural thing? I feel like that's like a I feel like you're entitled to to Java and ZedFS. I feel it's like That's right. Your that that is your your birthright as as a proud Canadian, I think.
Speaker 1:I've got kinda oh, Canada in my head when I'm
Speaker 3:alright. Pascal going forward.
Speaker 1:You know who are best. I've got my Molson light in my hand. I'm watching the Argos take on the tie cap. No. Have you ever watched the CFL game, Adam?
Speaker 1:Have you already had this conversation?
Speaker 2:I've only watched clips of the CFL.
Speaker 1:The CFL is amazing. And it It is amazing. It is amazing. And I I I I hear your tone. And on behalf of all Canadians, I find it offensive, and I think that you
Speaker 2:love to. I mean, I mostly watch it like I watch all sports, which is on John Boy as clips.
Speaker 1:John Boy would love the CFL. Has he done something He does love
Speaker 2:the CFL.
Speaker 1:Yes. He would love the c f the CFL. I love that man. I absolutely love John Boy. CFL is terrific.
Speaker 1:Anyway, the, the you you are entitled to your set of s and your and your Java, but you may not have Pascal. That is not a Canadian thing. That is a that's Step
Speaker 2:too far.
Speaker 1:I said it's a step too far. We're gonna you you you can have, you know what? They they also and I'm not sure if this is Acadian thing or not. The Canadians that I worked with called it called v I v I, which is kind of a that's a kind of a wild one. I I don't know if that's Canadian thing or not, but I think
Speaker 2:it's something to clip this from I have to cut this from the show. It's gonna be too controversial.
Speaker 1:It is too controversial. We're gonna get we're gonna get lit up. It's like in our attempt to settle beef with 1 podcast, we, like, picked fights with 15 others. We're we're gonna be on yeah. I'd we're, gonna be on daily.
Speaker 1:Has a podcast that has got a we're gonna be on a a podcast. It's gonna, Lucian Bouchard humor probably doesn't I don't know if that that really plays with the Oxide Fred's audience. Perizzo, where can I go here? Sean. These are actually you know, I realize these are Canadian politicians that predate you, Connor.
Speaker 1:You may be like, I don't even know who these people are because this is like yeah. Sorry. I'm just, like, caught up on the early nineties Canadian history.
Speaker 3:I was alive when, I think Jean Chretien was was PM. So I I definitely know who he is. Okay.
Speaker 1:Yeah. I I I got a finally. Exactly. I gotta like like a, but but Brian Mulroney, I think we can all forget. Sorry.
Speaker 1:We'll we'll get off of prime ministers of Canada here. The, but so Scott Myers had a rant on Pascal. That is terrific. And in particular so if you were I I take it from your podcast, you never implemented in Pascal, Connor.
Speaker 3:No. I have not. It's one of I'm I was gonna say few, but it's one of many languages I have not written.
Speaker 1:Yeah. And it's not I mean, it's it's not this is not like a bucket list thing. This is not like, although I am kind of I I I do kind of like the idea of just, like, your gamified running of city streets. We need, like, a city strides for programming languages maybe that, like, you gotta do. I I we can gamify that.
Speaker 1:But the, so this is not necessarily bucket list item. I would say that, goes one of the questions that you guys actually post, and we're gonna a little better word here. But one of the questions you post in your follow-up podcast is in terms of, like, y c, y what versus y Pascal or y ADA? Pascal actually was the systems language for the Mac in particular, and then not just the Mac. I mean, there were there were actually, quite a few systems for which Pascal was the systems language.
Speaker 1:You can do Pascal as basically c, more or less. It is the moral equivalent of c. It's it makes and now I'm and we're gonna have to we're gonna have to actually remove that too. We're gonna end up now Oh, yeah. Yeah.
Speaker 1:We will have to very short episode. War on the Pascal Podcasts are now gonna come after us to be like, they said what? No. This is what this is what we actually have beef. The, but Pascal was very very similar.
Speaker 1:And Pascal, but one of the differences is that in c, I mean infamously famously, you have the open brace, closed brace nomenclature to denote a block. It's obviously been used by lots of other languages. In Pascal, it is begin and end. And every end in the program has a semicolon, except for the last end in the program, which has a period. And the program begins with program, and it has to end with end period.
Speaker 1:And, there's just this great Scott Myers rant on, like, why? Why does the last end have a period? By the way, like, every Pascal compiler knows this, and if you make this mistake, it will tell you, by the way, the last end in your program has semicolon. It needs a period. It's like, you're a computer.
Speaker 1:You know it's the last end. You put one there. It was actually really, really pretty funny. And and Dan is calling me out that is a statement separator, not a terminator. Well, then you and there you go.
Speaker 1:So, Dan Cross in the chat, very strongly supporting Pascal's, period as a program terminator as opposed to a statement separator, which I I'm it sure is, like, delightful to explain to somebody who's just learning how to program for the first time in in in Pascal. But, anyway, Scott Myers is someone I I really enjoyed. I'm not sure how much of his stuff has kind of is he is he still active in the c plus plus community, Connor?
Speaker 3:No. He retired a few years ago because when I first started, I think, attending conferences in 2019 was the first one I went to, I think I had heard that, yeah, he he was in retirement and no longer actively attends or speaks or or is writing or anything like that.
Speaker 1:He has moved to a commune in Vermont, and will deal with an operator much more than a comma. I'm trying to make this all a new machine. Yeah. I will I will no longer overload op I've overloaded my last operator, says says Scott Myers. Alright.
Speaker 1:So you, Ed, you got the clip. You you played it for the the the cohost. I I guess, we we were a little surprised with the reaction. I think you were a little surprised with the reaction. Is that a is that a correct statement?
Speaker 3:Well, definitely. Well, I I should circle back and say to the the second clip that I I just was killing myself laughing while on this walk in Thailand was when, Adam, you said, There's a concept called concepts. And then Brian, you go you go, what? There's a there's a thing called concepts? And then you say, yeah, there's a thing called so, like, in in, like, 5 seconds, I think concepts is said, like, 6 times.
Speaker 3:And just the bewilderment of you, Brian, that, that there's a concept called it was just it was just podcast gold. And so I knew I
Speaker 2:knew I was gonna tell Brian this, and I knew we were moments away from who's on first. And it was gonna take, like, 10 minutes to unwind.
Speaker 1:Yes. That's the concept.
Speaker 2:What's the concept called? Concept. That's what I'm asking.
Speaker 3:It was so good. And, and so I'm like, the whole podcast start to finish is amazing. But that first 10, 15 minutes in. So, I knew I was going to go and, like, instantly after listening to it, I was like, I got to play this for Bryce to get his reaction because I think we are both on the same page as is, you know, indicated by our discussion that followed is that C plus plus from a process perspective is in, like, a very bad place. And there seems to be, like, a lack of acknowledgment of, like, every other modern language, you know, Rust Swift, insert modern programming language, that development happens asynchronously, not in person, 3 times a year at these committee meetings that are very gate keepy in terms of, like, having the money or the sponsorship to go.
Speaker 3:And, you know, it's the folks that are in power, you know and and don't get me wrong. They are volunteers that are putting in their volunteer time. It's nothing against, like, the individuals that are going. It's just it's been shown that there's a better way to do, language and library evolution, that it does not require hopping on a plane with, like, you know, a huge carbon footprint, etcetera, etcetera. And so I thought he was just gonna agree with basically everything I said.
Speaker 3:And I'm not sure. I mean, Bryce, I'm he probably won't listen to this because he famously doesn't really listen to podcasts. He I think maybe because he said he gave the book his endorsement that he felt, like he kinda had to defend the C plus plus side of things. And also too at the tail, because we had recorded 2 episodes back to back and we had just finished saying that we thought, you know, C plus plus was in bad shape. And I think he had said something like, you know, they weren't gonna ship any language features.
Speaker 3:And so, yeah, I was a bit surprised at his his reaction. And also to, I mean, he did acknowledge that. I thought it was a not to call Bryce, hypocritical, but, you know, he also has a ton of very hot spicy takes which is why I think he makes for an amazing podcast, co host because he says things that gets reactions out of people. And I think it's all
Speaker 1:accomplished there. Definitely mission accomplished. I mean, he did and you gotta give I gotta give Bryce credit. He did say one thing. I mean, I guess, like, because with you you didn't give him any context, and he didn't ask for any context.
Speaker 1:He's just like, alright. That's all I need. Like, I I got this loaded revolver. Time to start firing it. And I gotta say he did, like, absolutely nail the target in one of these.
Speaker 1:Adam, do you have a clip of of Bryce just absolutely nailing me? Yes. Yes. Yes.
Speaker 3:I do. Brian Cantrell was one of the voices, and he actually was a c and c plus plus developer, from years ago, but has just not used the language Yeah.
Speaker 4:Well, she hasn't been a c plus plus developer since, like, the nineties, I'm gonna guess.
Speaker 1:I mean, Scott, absolutely busted. Yeah. Yeah. So just to be clear, I have not there was actually a time when I had developed more c much more c plus plus than c. So I did a lot of c plus plus in it, but it was all in the nineties.
Speaker 1:So Bryce has
Speaker 2:As an undergraduate. Right?
Speaker 1:Like Yeah. Yeah.
Speaker 2:Or okay. Just just checking.
Speaker 1:Well, and also, I was, like, a big advocate for it. So, like, I moved the operating system course from c to c plus plus. And the did you not know that?
Speaker 2:No. But I'll talk about that later. I I I that's that's actually my last week discussed that.
Speaker 1:Okay. But, like, it sounds like you are okay. I'm not actually
Speaker 2:Now I know who to blame is what I'm saying.
Speaker 1:Exactly. Yeah. That's what I and I just you you know, that because I took this is in, like, 93, and c plus plus was the kind of the hot thing. And, it was the hot thing for a bunch of I mean, there were a bunch of interesting ideas in there. And I think that actually and kind of I would love your take on this.
Speaker 1:I think that part of the challenge that c plus plus has had is they, to the best of my knowledge, never really discarded an idea. That, like, when an idea gets into the language, it stays. Because more than anything, they have enshrined compatibility compatibility with c, compatibility with old c plus plus. I'm not sure maybe this has changed in the last I mean, be very reasonable for this to have changed the last 20 years. I know a lot has changed.
Speaker 1:But, certainly, at the time, the fact that you could compile c as c plus plus was really important. And that, but then it also led to a bunch of things that were then going to be design decisions that were gonna be have we're gonna be pretty consequential because of that compatibility.
Speaker 3:No. That's that's that's that's entirely correct. And I will say, because I wanna comment on, I, I do know, I think one of your best talks, Brian, is the Summer of Rust. And I think when I watched it a couple years ago, the top comment at the time was because I think it's an hour and a half or 2 hour talk. The top comment at the time was, I'm 50 minutes and the talk is entitled, The Summer of Rust.
Speaker 3:And the top comment was, I'm 50 minutes into this talk and this guy hasn't mentioned Rust once and I'm absolutely loving it. And then the reason I bring it up is in that talk, I believe that's the talk where you use the slightly edgy analogy of c plus plus being like an ex girlfriend that took all your clothes and threw them out on the street and lit them on fire. And I I understand that c plus plus is doing great now. They got all these new modern features. I'm happy for you, but I just, like, because of my experience, I can't go back.
Speaker 3:And I just I thought that was hilarious.
Speaker 1:That is exactly it. I mean, it is it I mean, almost like literally it. I mean, I had a, it it it was. It's like it's like this relationship from my past that that was important to me at the time, but also crazy in hindsight that, like, left me with some wounds, that took and I think also because I had been such a c plus plus advocate that when I kind of flipped, I and it was also at a time when the kind of, like, the prevailing zeitgeist was that c was absolutely dead. I mean, honestly, like, c was much more dead in 1995 than, say, than c plus plus is today.
Speaker 1:I mean, I I don't know what the analog would be today. I mean, closer to not quite COBOL, but, I mean, it it it was just like no one should ever do any c. That is clearly not gonna be the future at all. And I had kind of when I, myself, had this moment, which I came, like, hours in to I was trying to instantiate a list template and was running into 2 separate compiler bugs. So this is another important thing to know about my own personal experience is the compilers didn't work reliably.
Speaker 1:And, Adam, I mean, you were I mean, I I don't think they were completely working. You mean, you were a couple years behind me, but not so far behind me. I'm sure you had some of the same issues with compilers misbehaving.
Speaker 2:Yes. And we were deep into, like, templates being in vogue. And
Speaker 1:That's right.
Speaker 2:So even when they did work, you would get I mean, I guess, glass houses now with Rust, but, you would get inscrutable error messages that went on for pages and pages and ended in a seg vault.
Speaker 1:Right. And then and then the fix was to blow I mean, at least at in my day, the anyone would tell you, like, have you blown away the templates on d b file yet? I mean, it's like you would need to, like, constantly having Of course.
Speaker 2:Right.
Speaker 1:Blow away the compiler's internal state, and then, like, then it would work. And it is you know, as as a developer, you know, those things will and this is part of the reason why tooling is so important because, like, that begins to chip away at you. And it because it's like, this is not related to my like, what I'm actually trying to do. And the whole purpose of using templates is to save me time as a developer. Like, it's ultimately what we're trying to do.
Speaker 1:We're trying to allow me to deliver a high quality, high performing software artifact faster. And every time I need to blow away templates on DB, we undermine that particular value proposition. And I just broke after this, like, I had this I I was trying to debug the the these these I, you know, I realized I had 2 separate power bugs. And, Adam, you know, like, when you when you are you've got, like, 2 bugs in play, and it feels like the they kinda reinforce one another in in ways that feel random that you can't it's, like, 3rd behavior. And I was just, like, I was so frustrated, and I'm like, why am I I know how to write a link list.
Speaker 1:I just
Speaker 2:You're, like, when you start, like, losing sight of, like, what was the actual problem I was trying to solve before I went 6 levels deep in this bug stack. Right. Yeah. You're like, why am I here?
Speaker 1:Like Why am I here? And that's when I kinda, like, walked away, and I'm like, I and my career was in c from the from more or less than on. And I actually kinda thought with Java that there would be no more c plus plus, honestly. I mean, I the the with the kind of the rise of Java, I'm like, I don't know why one would write c plus plus. I think the answer to that is, like, people were try it was really around performance.
Speaker 1:I mean, Conrad, correct me what what kind of your read is on c plus plus development post Java. I think the emphasis is on I mean, Adam, is that a is that a fair read? Is that the performance I mean, absolutely. Because they're coming to Google.
Speaker 2:Early days, you didn't even have, like, hotspot or, you know, some of the JIT stuff was very, you know, new. So Right. Yeah. I mean, you were not writing high performance Java. Right.
Speaker 1:Right. And I think that, like, you know, the it's a it's it's a challenge because, like, at what time should c plus plus probably have broken from its past? And this is the what I would call the underbar, underbar, init, underbar, underbar problem. So this is the because the Python the name of a constructor in Python is underbar, underbar, init, underbar, underbar. Because when they introduced the the idea of an object in Python, which, I mean, someone who knows Python well can tell you this, but this is like in the early nineties, when there are when there is certainly, you know, 11 thousandth of 1 percent of the total Python had been written, and they didn't wanna break things, understandably.
Speaker 1:And but now you've got this work that you've gotta bring forward forever. And, you know, my daughter learning, you know, my 11 year old daughter learning programming is like, what is this? It's like, yeah. It's an underbar underbar and then underbar and right. Sorry.
Speaker 1:It's just, like, don't get me started. I'll point you to a shock.
Speaker 2:And you're and you're right on you're right on, like, c plus plus. I mean, the point of or one of the big points of that beautiful c plus plus book was, hey. We've been we can compile KNRC that from 1971, probably not literally true. But, and we've needed to carry on that legacy, So all of the defaults are busted, and you should do hold it this way instead. So yeah.
Speaker 2:Anyway, Connor, when when you played that clip, I I I feel like there's both agreement but reluctant agreement, especially because we've got the the stink of rust hanging on us. And I think that That's true. I think, you know, like accepting observations, even observations just parroted from c plus plus books by folks associated with Rust is, like, tough to handle.
Speaker 3:Yeah. No. And to get back when, Brian, you mentioned about backwards compatibility, like that is completely correct and is going to, I think, retrospectively looking back on it, play an important role in, like, how these languages, like, how the cookie crumbles. Because inside the inner C plus plus community, it's a well known thing that at one of the 3 committee meetings that take place annually, one of them was actually the last one before the pandemic, was in Prague, Czechia at the beginning of 2020 in February. It, there was a big meeting.
Speaker 3:So I could and for those that aren't, that are listening, that aren't familiar, the way that C plus plus it has an ISO standard And there's basically a collection of folks, you know, back in the day it was, I think, only 30 or 50 that would meet at these meetings, but now it's up to 250, 300. And it's a week long meeting that they rotate between Europe and North America. And they have 3 meetings a year, once every 4 months. And there are a bunch of different groups that meet and focus on library evolution and language evolution. And so one of these was in 2020, in February, right before the pandemic or right when it was starting.
Speaker 3:And I was at, I, for a couple of years, was attending these, and was at that meeting. And there was this I think it was a 2 or 3 hour session talking about, should we change the sort of status quo of not breaking backwards compatibility? Like and there's some people listening that they're thinking, oh, I know this feature, that feature, we technically did, you know, take out. There are there are a handful of things you can point at, but in general, it is an unspoken rule that you do not break backwards compatibility because that's one of the strengths and reasons that c plus plus became so popular was because of its backwards compat with c.
Speaker 1:Right. Totally true. Right? I mean, that is totally true. I mean, that is certainly a very important it plays a very important role.
Speaker 3:Yeah. And this, you know, question of how to evolve is playing a large role in the design decisions of these different successor initiatives. You know, CPP front or CPP2 is aiming to just basically be, at the moment, take the c p the cfront route, which is just basically a syntax that transpiles down into existing c plus plus code. Whereas Carbon, out of Google, is aiming to have a really good interop story, but it's gonna be a different language. Whereas Rust, you know, doesn't really have a great at the moment c plus plus interop story.
Speaker 3:But, to to wrap up, you know, long story short of this meeting took place and the the vote that happened at the end basically was like, we're not gonna change the status quo. And that was the meeting that Google, who was one of the largest investors in C plus plus they The chair or the editor of the standard worked at Google, Chandler Carruth, along with that individual was Richard Smith, who was one of the 3 people sort of leading the leadership team on Carbon. And Chandler Carruth was, I believe, running one of the groups there. Like, so a lot of very senior people with many decades or years of experience, basically cut I don't wanna say pick up and left the committee, but that's essentially what happened. And, you know, you know, modulo a few details.
Speaker 3:So it was a couple really important folks as well as their coworkers basically pivoted from, well, we care about perf. We have our own library at Google called App Sale that has all these, you know, data structures that aren't standard but are faster because the hash map that we implemented, you know, isn't able to do x, y, and zed because we can't break backwards compatibility. And now they're working on Carbon. And in hindsight, some folks I'm I'm sure, are gonna say, like, that was a mistake in c plus plus history. Like, the folks in the room, I don't think understood the implications of making the decision to continue maintaining backwards compatibility.
Speaker 3:And that's not to say that, like, Google and the folks there wanna break every 3 years, but, like, they were like, the c plus plus was not solving the problem that they were using it for. And so now this is why, you know, carbon is a thing. And I've heard out of multiple folks on the committee basically start to talk about maybe we should have, like, a once every 30 year ABI break. That gives us the, possibility of, you
Speaker 1:know every 30 year something might break. It's like a jailbreak or something. That is like a it's like a solar flare. I mean, it's like a part of the creek. What's the analog?
Speaker 1:It's like, oh my god. We're coming up on the 20th. Yeah. Haley's Comet. Yeah.
Speaker 2:Exactly. Yes. I sort of enjoyed the hubris of it. Like, Brian, maybe every 30 years on the podcast, we should do something special.
Speaker 1:I think I do. Yeah. I do. Yeah. Exactly.
Speaker 1:Like, without fail? Currently every 6 day, I feel.
Speaker 5:I mean Sure.
Speaker 1:I mean, for for for a podcast that will last 10000 years, that, you know, that that really adds up. That that that's a lot. I think about it. Yeah. I mean, it is and I a point do I see both sides of that.
Speaker 1:Because on the one hand I mean, yeah. Obviously, like, we need to evolve the the language. We made to do it in ways that break things. But I got the other side of it honestly is like, hey. Wait a minute.
Speaker 1:If we're like, the value of this thing is its backwards compatibility. And if you're gonna eliminate that, I will just go to a different language that actually doesn't have the I mean, I I mean, this is like, you know, that that they they say that the totalitarian regimes are are most likely to be toppled when they try to reform. Because, you know, you you you are trying to actually not I guess I mean, not to compare c plus plus to attach to your g, but I I guess I just did. But the the you know, that when you have glasshouse it's like, yeah, it's most likely to lead to the fall of the Soviet Union because, you know, people don't wanna have, like, a little freedom. They wanna have a lot.
Speaker 1:They wanna have all of it. And it's like, I would say that I, I would question if I were in c plus plus, I'd be like, wait a minute. If I'm, like, if we are gonna add on the one hand, I wanna add things like patterns. So, I mean, I'd I mean, for me, and I'm Russ. I know Adam, you and I have talked about this in the past, but, boy, like, just just pattern matching alone.
Speaker 1:Just pattern. And it's, like, so changes the way you write software at such a deep level that, I would not wanna not have that. And I'd I kinda think that that was one of the things you're saying is, like, that is not gonna happen, or is, and I don't know if that's backwards compatibility reasons or not. I mean, how many of these things are not happening because it's impossible to make them backwards compatible, versus, because I think the other thing is you can have the kind of the the the the the scepter of backwards compatibility, where you can actually do quite a bit without breaking it. But that that that said, c plus plus has got a lot of really strange behavior that it's gotta be backwards compatible with.
Speaker 3:I mean, pattern matching is in the evolution pipeline and it was first brought to the committee back before the C plus plus 17 standard. In fact, it was initially brought as a single proposal with variants, a. K. A. C plus plus as some type, if you're familiar with algebraic data types, AKA the equivalent of enums in Rust.
Speaker 3:And the committee said this proposal is too big, split them up. Variant ended up getting in as a language feat as a library feature in C plus plus 17. And pattern matching has had a whole history of initially there was one proposal, then there was 2 competing proposals. I think there's only 2 active competing proposals, but at one point, like, while there was 2 competing, there was a third one that showed up, that Herb Sutter was proposing like is and as, which I definitely don't think is gonna happen. But anyway, so now there's multiple competing proposals, but, you know, this has been going on a decade now of, you know, trying to get this in.
Speaker 3:And I you know, Bryce says he doesn't think it it'll ever ship. I do think at some point, pattern matching pattern matching will get in, but also it's it's not gonna be anywhere. Like, if you read the proposals, the syntax so that's the thing is I don't think really there's much that c plus plus can't implement because of backwards compatibility other than, like, changing the defaults and and, you know, like, we got Lambdas in in c plus plus 11, and that was already on top of, like, a a bunch of stuff. Some people would say a ball of mud, but, like, we got it in. The syntax for it is absolutely atrocious compared to a language like Haskell or even Rust.
Speaker 3:Like, you need every single type of of, you know, I'm I'm I'm a a pedant when it comes to the naming of braces and brackets and parentheses, but you need every single one of those. You need, you know, the the brackets for your capture list even if you're not capturing anything. You need the parentheses for your parameter list, which you can omit if you have no parameters. Before that, you need your, chevron, you know, angle brackets, which was, I think, added in 14 or 17 if you want to templatize, your parameters. And then you need your braces for the body of the Lambda plus a couple semicolons at the end of your Lambda unless if it's immediately invoked.
Speaker 3:Anyways, like, you know, c plus plus engineers, they're paid well. But it's like, it's to learn all this stuff and and then you look at a modern language and you're like, wow. Like, I look at Haskell and then my mind is blown. It's like, you need 2 parentheses and that's it to form a section, which is just like a a shorthand for for and so like c plus plus does and is able to implement these language features. It just ends up looking, you know, I I don't wanna say horrific compared to other languages, but it's just a lot worse because we're doing it on top of, you know, 30 years of history, which is unfortunate.
Speaker 3:But, you know, so I pattern matching will probably show up. It's not gonna look as beautiful as Rust or, you know, any functional language that has first class support for ADTs and pattern matching and such. But, you know, it is what it is. The, the, the committee is doing the best they can, you know, with what they are are trying to achieve, which is backward compatibility.
Speaker 1:And so what is the disposition towards Rust? Because I I did think one of the thing that was interesting I I don't know how representative Kenne Price is on this, but, the fact that Adam is emblematic of everything that's wrong with Rust because, the the, Adam Rust supervillain. Because I I did think it was kind of interesting that there was a bit of othering going on in terms, and and this is where you do get to kind of, some of the of of the tribalism that I do think is problematic. Right? When you I think it's actually is really important that we develop our own domains of expertise and languages and systems and so on.
Speaker 1:But we also need to look outside of them for innovation that's happening elsewhere to kind of bridge the and I don't know. Connor, I mean, you're obviously someone who who has done that because you are in in different languages and so on. But I it feels like that's not always happening. It's true of all communities, I think. I think all communities have this problem to to a greater or lesser degree.
Speaker 1:First of all, is that a fair read? What what is the disposition actually? Let me ask this. What is the disposition towards Rust in the c plus plus community if there's a prevailing one?
Speaker 3:I think it is a mortgage board. Like, it depends on if you ask the community as a whole, like, you're not gonna get a singular answer.
Speaker 1:Yeah. Right. Right. Right.
Speaker 3:I definitely know there are a number of folks that are actively on the committee that are huge fans of Rust. I I won't name any by name, but I definitely, seen folks on panels and seen folks in talks that are alluding to, like, look at how Rust does this, you know. Isn't this awesome? I wish we could have this. So there's definitely people that, you know, are actively working on evolving c plus plus and paying very close attention.
Speaker 3:And I think for some of them, they actually like Rust better than C plus plus but they work at a company where, you know, they're not gonna be, you know, taking their tech stack, which has millions, if not, you know, tens or 100 of millions of code written in c plus plus, and importing that to Rust. So, there's definitely folks like that. I think that there are other folks that are not big fans of Rust. I know several people personally, on the committee and off the committee that there are just certain things that Rust does not have the capabilities of doing. I think the number one thing that comes up is, variadic generics.
Speaker 3:And like, I've literally heard this quote that like a language without support for variadic generics, like I it's just a non starter for me. And I've I've I've I've both I've I've asked this question to a lot of folks, to try and appease those people, like, how do you deal with a kind of problem, You know, like my the easiest one or my favorite, because it's kind of algorithmic is we we got a new, quote, unquote algorithm in c plus plus 23 called, zip transform, which basically is the combination of zip and map. So instead of having to destructure the tuple that a zip will give you, it'll just automatically apply, your binary or or whatever arity operation to your zip together sequence, which is a nice convenience. But if you try to spell that in Rust, you know, it looks okay in the in the case where you're zipping together 2 sequences. But what if you're trying to do that over 3 sequences or 4 sequences?
Speaker 3:And I asked a Rust pro this, and he said his answer was I would just zip twice in succession. So that the type that the tuple type that you end up with is a tuple where the first element is a tuple and the second element is just your element. And so but because you have destructuring in the, parameter list of your Lambdas in Rust, you could you'd know the shape of that tuple. And so you can just destructure everything, call the internal elements a, b, and c, and you're done with it, which is not as elegant as what you can do with c plus plus because our zip transform is variadic. You can you can, zip as many sequences as you want and apply the corresponding operation with an arity that is equal to the number of sequences you zip.
Speaker 3:So, like, in this one tiny example, like, because c plus plus has very added generics, we have a more elegant way of solving this problem. And when I pointed that out to the guy, he was like, well, honestly, that's true. But, like, this is a very specific example. And the niceties that I get from the tooling and the language and the memory safe safety and, like, everything that I get with Rust is, like, I would rather pay that cost of like having to write that, you know, or there's an IZIP macro if I really don't wanna zip twice in a row. And, and so like his sort of response is like I acknowledge this isn't as nice in Rust, but, like, I don't care.
Speaker 3:Rust is a a way nicer language. And, like, I I will pay that cost when I have to pay it. And, and so, yeah, that I'm not sure that was a long winded answer to some folks love Rust. Some people won't touch it because it's missing certain features. I think others have a ton of experience and not like a sunk cost isn't the right word, but they they don't want to be in a situation where Rust is now the the go to systems language and c plus plus goes the way of COBOL because then their 30, 40 years of experience is, gonna need to be translated.
Speaker 3:And I think that's actually a huge issue. Like, I talked to some folks and it's very hard to have a conversation about rest because they it's almost like an emotional reaction. Like, you're you're trying to, like, you know, devalue all my expertise. And it's like, woah. I'm not I'm not trying to that's not what I'm trying to do here.
Speaker 3:I'm just trying to, like, point out that Rust has a lot of great stuff that, like, c plus plus doesn't. Sure, it's missing x, y, and zed, but does that does that make it, not as good a language as c plus plus Like, anyways, I I feel like someone joined this this speaker table, and I'll let I'll let folks respond to what I said.
Speaker 1:Yeah. So and, yeah, we're gonna get, cliff in here in a second. Well, so a couple of things come to mind. 1, I just to to take your latter point there, I and I think that this is really important, because I've seen this in a couple different communities. Definitely saw this in c when Java and the kind of when it was Java Java Java.
Speaker 1:And as I where Adam and I literally ate at a cafe called the Java Java at Sun, and everything was Java Java Java. And it felt like anything that was not Java was was, legacy, and that there's a there's a sense of fear. And I think that, you know, I've I've recommended this talk in the past, but Rachel Stevens gave a terrific talk at last year's Monktoberfest on the the the root of much kind of bad behavior is fear. And fear and the kind of the fear to get being able to to express that fear is really important, because I think people feel personal fear. They feel like I mean, just to counter to your point of, like, wait a minute.
Speaker 1:If we're gonna discard the language, I mean, am I getting discarded? Am I is my expertise no longer valued if we no longer value this this particular artifact? And, that that's really tough. You know? That's really tough to kinda confront directly, and but I think it is actually really important to to to convert it directly.
Speaker 1:The other thing I I I think it was coming to mind, Thomas, you're talking about variadic generics. And I guess I've never I've never used variadic generics, so I don't know how life changing they are. This is where I'm gonna wanna turn over to Cliff to get to get his perspective, but it does seem to be like the small differences, where it's like the the the difference I mean, like, okay. So if we add variadic generics to Rust, I mean, what or if they are added, I should say say we, because I'm certainly, I would have nothing to do with that. What would be would what would be the next thing?
Speaker 1:It would have been an even smaller difference. But, Cliff, you've used periodic generic and c plus plus. You've done a lot of c plus plus work and, obviously, a lot of Rust work. What what's your what's your kinda take on these 2 different communities?
Speaker 5:Okay. So the end of that sentence kinda changed the question. I'm I'm not
Speaker 1:Oh, sorry. Do you you you did it right away, but other answer.
Speaker 5:I miss periodic generics. Holy crap. I was saying this in chat. Like, they're one of those c plus plus 11 features where you mostly only use them inside of libraries, like, if you're writing a boost library, but the effect that they can have on ergonomics for your end users is just massive. And when when people say Rust doesn't need this, I point to the function types, which effectively, sort of like how Go has generics as long as you're Rob Pike, c plus or Rust has gen variadic generics as long as you're writing the support for the function types, which effectively are variadic generics for the arguments.
Speaker 5:Now that's not really how they're implemented, but the thing this would let us do if we had it, and I'm not sure that we should add it, but if if we did, is to be able to implement like a trait for all possible tuple types without having to write it for 2 tuples and 3 tuples and 4 tuples and so forth.
Speaker 1:Got it. Which is, you know, kind of yeah. That'd be horrible.
Speaker 5:But at the same time, like, is this enough for me not to use language? Well, certainly not right now. And I I did wanna add something about fear. So, I've been trying to figure out how to talk to, you know, talk to your kids about rust. I've been trying to figure out how to talk to people about rust in a way that they'll be accepting of for several years now since I was trying to do it at Google.
Speaker 5:And I think you're absolutely right about fear, and we also run into a problem, which is that due to the demographics of systems programming, and I'm saying this as an aging white guy, we're not great at talking about fear. Like, I have brought up fear as an origin for this, and I have had people explode at me and end the conversation.
Speaker 1:It's
Speaker 5:confirmed. And I totally sympathize with fear. Like, it's the same sort of thing I feel like if I'm like, if I've invested a lot of time getting good at Rust, like, if another language if Carbon were to went out, would my time be wasted? Which I don't think it would because I've learned a bunch of stuff, but, you know, I I I sympathize. So I think if we could get better at talking about the things that we're afraid of and the things we're trying to achieve and not focusing so much on turning it into adversarial, I think it would
Speaker 1:work better for all of us. I think also if we can kind of find ways to allow people to move into a different world. And, I mean, Cliff and I have talked about this in the past about kind of bringing you know, what elements of the old world can they kinda bring with them as a comfort? And, certainly, the one that that comes to mind. And, Adam, I don't know where you are on this, but, certainly, in when I first started implementing in Rust, all of my comments were c style comments, or I should say, I guess, p l one style comments, but were of the slash star star slash variety.
Speaker 1:Yeah. And I don't know. Are you I don't know if you ever if you went through this phase or where you are.
Speaker 2:I did the same thing, but I, you know, I embraced Rust format, I think much earlier than you did. And, and actually also tried to convince some of our other colleagues like Dave Pacheco about the the beauty of Rust format and Rust format sort of, cured me of my c style comments because it fucked them up every way. In fact, I contributed I contributed multiple PRS to rust format, basically as an apology to Dave for forcing him to use rust format with his d style comments. But, yeah, I I I I brought the new a little bit of the old world with me too.
Speaker 1:And I felt like that was, like that I that was, like, psychologically important for me, personally, as I was kind of venturing into the new world of Rust. And this is obviously coming from from c and not c plus plus. And then it's also, like, it's also true that, like, c plus plus comments, it's like now you get to, like, the, you know, the the the college relationship with that ended poorly. And, and I'm realizing, Adam, this is gonna completely come from because you and I I find myself missing is now c plus plus style comments in d trace. Indeed.
Speaker 1:Yeah. Which is, well, well, well. Look who's adding a new copy. So I'll I'll I'll I'll gotta get that fixed at some point. But so I I think that, like, you know and, Cliff, I'd be curious about what your thoughts are having dealt with.
Speaker 1:I mean, you've dealt with a lot of folks coming to us from different languages. And, you know, what have been kind of where you see them having allergic reactions that are, like, not well founded, founded, that are just kind of, like, part of this, like, this is different, and that, therefore, I am I'm attacking it only because it's different versus, like, hey, just take a second and and learn it.
Speaker 5:Oh, boy. So it's super easy for us. I think people who interact with code all the time as our job, as our hobby, as a significant fraction of our life to be really sensitive around syntax. So I'm just gonna skip right past that. Because I think that affects every language, and I don't think it's very I mean, on some level, it's interesting as a human factors issue, but it's it's not very interesting in what it tells us about Rust or c plus plus or anything like that.
Speaker 5:It's just unfamiliar bad. Oh. Some of the things I ran into early on have since been fixed, but, like, so Rust has opinions about the fact that type should be capitalized, for instance. And this actually caused an engineer I respect a lot to completely bounce off the language first thing because that that seemed incredibly foreign to him. And, at the time, the lint you had to turn on to get the compiler to shut up about that was called allow bad style.
Speaker 5:So that was kind of rude and
Speaker 1:No. I'm not it's not a value judgment. You just have to disable value judgments in order to be able to compile your code. So what's the yeah. Wow.
Speaker 5:Yeah. So that was I think whoever did that in the compiler probably didn't think about it that way, and it it is now different. Other than that, I think a lot of people bounce off of Rust because of the complexity. Coming from c plus plus, the you're less likely, I think, to bounce off due to complexity, but Rust has more going on than c or than Python. And I it it's at an interesting sort of point of irreducible complexity if you want to have certain goals.
Speaker 5:Memory safety and trait based generics are the 2 big ones that have interesting interactions. And I feel like you could write an entire book on this. I was actually talking to Brian about this this morning, but like, I think Rust is complicated. I also don't see what to remove and maintain the goals that I'm trying to get out of the language. So, Zig, for instance, decided to punt on both memory safety and race condition safety in the language design, which is a trade off you can make.
Speaker 5:I would be and and Zig is a much simpler language as a result. But I want freedom from data races and memory safety, and I would love to see a much simpler language achieve those while maintaining Rust's bare metal performance characteristics. I'm just not sure how to do it. I haven't seen any existence proof yet. So, when when somebody has it, please send me a link.
Speaker 1:Yeah. And I think that it's I mean, the other thing, just because of of this kind of grand bargain that Rust makes with you. I mean, Rust brings so much to you, but you gotta meet it a little bit. You you gotta travel a little bit, and I think that the distance that you have to travel, I mean I do think it's you gotta learn it. I mean, you you it's very and, Adam, I mean, this is like your, I mean, original Rush blog post from back in the day that if you try to kind of, like, bounce around and then when when you were learning it, there were, like, there's, like, the compiler was in a different state, there were less resources available, there were fewer books on it, there was no narrative to go on, and it was just harder to not, like, bounce through it.
Speaker 1:But you really do need to sit down and be like, I'm gonna take this time to really learn this. You just can't copy and paste off the Internet the way you can with some other languages, frankly. I mean, you can do that with Go, I think. I mean, I don't mean to that, and I don't that's not pejorative. I think that that is that's that's arguably a strength.
Speaker 1:And you can certainly do that with JavaScript and not really know what exactly is going on and still have a functional system. But then, you know, you kinda shifted the cognitive load away, and then it comes to bite you later is kind of the rust thesis. And that's not that's not a fit for everybody. I do think it's actually really important to know that bargain going in, because I have to say, the the, Programming Rust book, the O'Reilly book, makes this really explicit about this bargain that you're striking. And it did like really help change my disposition to the power checker of like, okay, I need to, like, really just instead of just trying to kinda throw myself at this thing and bloodying myself against this immovable object.
Speaker 1:I need to, like, step back and appreciate what it's giving me and be willing in particular to change the structure of my program. Because Cliff, I think that's, like, a pretty big and important thing in Rust that you if you got a preconceived notion of how you're gonna implement it coming from c or c plus plus, Rust may wanna Rust may want you to consider a different approach.
Speaker 5:Absolutely. And and there's a lot of data structures and even some algorithms that don't work well in Rust because we haven't yet figured out how to explain to the compiler in a formally provable manner that they don't violate aliasing, that they don't, you know, reuse pointers outside of their appointed lifetime. And I write particularly in things like graph algorithms, I approach things very differently than I would in C plus plus and I have to. And that was a hard learning curve for me, consisting of a lot of cursing and going back to other languages early on. But you know, is this a good feature of Rust?
Speaker 5:Not necessarily. The code I produce is sometimes more efficient than it would have been, but sometimes it's not. And I think different languages want different shapes, want different 4th is my, this is probably not going to resonate super well with the audience, but 4th is my go to example of this is that, like, 4th really is a language that needs different approaches to things than most other languages. And the way that you do something ergonomically in a way that will be maintainable is very different from how you do it in C. And I feel like the C to Rust gap is in many ways similar, less similar than the cedar, Haskell gap, for instance.
Speaker 5:But yeah.
Speaker 1:C to Haskell being a bigger gap, in other words.
Speaker 5:C to Haskell is a is a much larger gap. Yes.
Speaker 1:Yeah. I mean, sorry, Clint. Go ahead.
Speaker 3:No. I was just gonna comment on what, Cliff said is that I've had this conversation with a luminary of the C plus plus community who has, I won't name, but has given keynotes at large conferences and almost any C plus plus developer that, you know, watches, talks and listens to podcasts will know their name. And their opinion is that what Cliff just said, and I know Brian, you've made this point. I think it was in your, you know, Rust OS talk that, you know, the the folks that show up at Rust's door and try and do a doubly linked list and then have trouble with it, and they say, okay, I can't do this, you know, Rust bad. Like, this person's opinion is that if I can't, if I if you're telling me that I can't, you know, implement a linked list or a double linked list easily, then it's just a bad language.
Speaker 3:Like, you're you're telling me I can't express that? Like, how how how should me needing to go down a different path? How is that, like, you know, the the the correct way or, like anyway, so, like, I've I've had this conversation being, like, trying to quote, basically paraphrase what you've said before, Brian, and what you just said, Cliff. And they're it's just like a it's a it's a stone wall being, like, you you can't tell me that I'm not allowed to do like, program the way I know how to program. And I'm like, well, okay.
Speaker 3:And it's it's, it's an impasse. Like, I've I've had zero success with certain individuals telling them and and paraphrasing what you've said in your talks and what you just said, Cliff. Like, they just don't, accept that as, like, an acceptable answer.
Speaker 5:I actually completely agree. And I think that's that's an underappreciated thing people bounce off of is bringing a data structure you're very familiar with. For me, it was intrusive doubly linked lists, which, like in an operating system kernel with real time requirements, intrusive doubly linked lists are a great data structure. They're also really difficult to get right for an expansive definition of right. And so one of the things I've been doing recently is trying to write a correct one in C and the definition of correct that you use there is really important.
Speaker 5:The number of things you have to document that you cannot do, for example, struct return, struct assignment that the compiler won't stop you from doing. But, you know, anything with internal pointers, struct assignment is not safe. Rust knows this and as a result will reject your program. That's not great. It'd be nice if your program would work, but I think one of the things that's underappreciated about particularly intrusive doubly linked lists in other languages is, like, they are relatively error prone and pretty easy to come out with dangling pointer errors, And that's actually, the reason why they're hard in Rust more or less.
Speaker 1:Totally. And a cliff, it's funny you should mention that because that was basically from me too. It's like I was I was reimplementing this thing that had used, an intrusive AVL tree, which we use all over the place in the kernel, and and then ported to use land. And it was it just, like, it's super easy to use. I am, like, really curious.
Speaker 1:I don't because you obviously use Libavio a lot too. Yeah. What implicit things do we know to avoid with it? I'm not sure. I mean, it's I I think that the the big thing that you give up there is that it you it it cannot I mean, it is very, it leaves much up to the thing that it is being embedded in.
Speaker 1:So there is no locking in Libavl. It's like, that's up to you. That and so and and and, Cliff, I don't know. Maybe from your perspective, that'd be, like, well, that's a, like, easy to get wrong for sure. And it is As long
Speaker 5:as as long as something in the type system prevents you from using that code across threads, but that's not a currency, unfortunately. Yeah.
Speaker 1:Yeah. That would be a negative.
Speaker 2:I mean, like, when you're deleting something, an entity that exists in multiple trees, I feel like I'm guaranteed that's a guaranteed, like, par 6.
Speaker 1:It's it's telling
Speaker 2:me. That right.
Speaker 1:And there's a great power in the like, you've got an object that can be on, like, you know, 5 different data structures simultaneously and with which we definitely do in the kernel atom with I mean, there's a lot of CFS data structures in particular that were on, like, a whole lot of different trees at once. And, yeah, easy to get that wrong. Easy easy to forget that you were, so the the there's a parallel there for sure.
Speaker 5:I I haven't used that particular library, but off the top of my head from your description of it, I suspect that there's a couple of things that are potential foot counts here. One is that you've got very what I would describe as challenging alias situation there with your, with your thing in multiple trees that may have other overlapping nodes. And so deleting things as Adam pointed out can be very challenging. But even just mutating things safely could be challenging, because of aliasing. The other thing is, particularly if you've got an object that can be a member of multiple intrusive data structures like an intrusive linked list or an AVL tree, You always wind up needing to upcast.
Speaker 5:I guess it depends on your or downcast. You need to be able to go from a link, a node that's reached by the pointers in the generic data structure up to the container type. That method, which is either punning and assuming it's at offset 0 in the struct, which please don't do that, or a container pointer, which you can totally afford. Please use a container pointer. That in itself is another thing that is easy to get wrong, particularly if the struct is moved or if the, container pointer is corrupted or otherwise initialized wrong.
Speaker 5:So these are a couple of things that if I were interacting with a library like that, I would be keeping in mind to try to avoid doing wrong.
Speaker 1:Totally. And when you create the ABL tree, you are indicating, the you're indicating the offset in the structure that contains it. So, I mean, that's kind of very explicit in the contract.
Speaker 5:Oh, wow. So you're you're failing, like, offset of and and telling it on creation?
Speaker 1:Yep. That's right.
Speaker 5:Yep. I'm sure nobody ever gets that wrong.
Speaker 1:You know, it's like you it well, I would say it's it's not that I I think you don't actually get that wrong because if you do get that wrong, it's just like nothing works at all. I think what it does mean though is that there are just, like, huge compromises that you're making that then become and in particular, like, obviously, because it's interested in the structure, it you've got no ability to turn that into a smarter data structure. That's gonna be an AVL tree, not a B tree. The end. Right?
Speaker 1:There's just no real way around that.
Speaker 5:And Plus, since you're working in c, you're inevitably gonna wind up casting a void star some specific type. So if you insert a thing with the wrong type, that can become very exciting.
Speaker 1:Yeah. And the and I think that we, you know, the reason we did we did that obviously is for memory efficiency. I mean, the reason you use an intrusive data structure is memory efficiency for for for performance. And for me, the thing that I had to let go of it when I was well, when I had to let go of this as I actually really tried hard to make this work in Rust, and I'm just not smart enough. It's what we both sound too.
Speaker 1:I mean, I was just like, I am just getting mauled. And, I you know, there's the there's that blog entry, so you really wanna write a double link list in Rust. And, like, the tone of the blog entry is, like, don't do this, which apparently, and I'm like, yeah. Yeah. Don't do this page down.
Speaker 1:I want, okay. Yeah. Let's do this. They're like, no, seriously. Like, don't do this.
Speaker 1:I'm like, yeah. Yeah. Let's but I wanna go do that. It's like, hey. Hey.
Speaker 1:How many warnings do you need, pal, before you just, like, don't do this?
Speaker 5:I mean, part of it is that until fairly recently, the semantics around that were formally undefined
Speaker 2:in Rust.
Speaker 5:So I've got one on GitHub that's a worked example of a doubly linked intrusive list that I believe to be correct ish and that will I see Ben Kimach in the audience. It, this will actually pass tests on MIRI, which is the undefined behavior checker, for Rust, one, one of the undefined behavior checkers. But I use that data structure because of the determinism it provides, but it is, implementing it in Rust certainly makes me think very explicit all of the things that would have been comments in my c implementation. And I agree with that tutorial that this is not a beginner task.
Speaker 1:It really is not. And then it's and when if you were to bounce off the language then, it's it it would just be sad because it's like you're bouncing off the language for kind of the wrong reasons. It's like you have kinda accidentally put yourself into something that is just that the language makes really really hard because of the things it gives you on the other and I think if you kind of go into it thinking of, like, I'm gonna get these kind of magical things if I'm willing to change my thinking. It's and I I and I think that we you know, it's in Cliff, you've got a terrific blog series on learning Rust the unsafe way, for c programmers in particular, as, and and what's what's been the reception to that actually?
Speaker 5:I mean, the people I hear from the reception's been pretty good. I don't know what the reception's like among the people I don't hear from, obviously.
Speaker 1:Yeah. I guess it's fair.
Speaker 5:I suspect I mean, I I guess I could go search the orange site, but I don't as a matter of policy. And, that that's actually my second attempt at convincing my c programming friends because most of my friends are systems programmers, at least work friends. And convincing my C Programming friends that maybe they should give Rust a try, that it's that it's something that might be interesting at their level because my first one was, well, it's still on my website, shall we say less tactful and was far less effective. So I regrouped and took a different approach and tried to be, and this comes back to some degree to the fear thing we were talking about earlier, but also to the cultural holdovers and and cultural comforts that you mentioned earlier, seeing that you will be able to do this and still apply your skills. Right?
Speaker 5:That you will be able to take some of the data structures, you know, from your past life and apply them. That and and this is actually a point that I think is underappreciated that I was hoping to get to in a future section of that, except that I got a different job instead. The, there are a lot of data structures I use in Rust that I would not use in C and it's because they would be cowboy in C, like learning sections of my stack to other threads, like, you know, sharing aliased pointers to my stack with an interrupt handler. There are things I can do in Rust that I can do that I know would fail at compile time if I got them wrong that I would never have reached for and see. So it's not like there's a one-sided trade off where you can't do the data structure in rust.
Speaker 5:It's each language has data structures it's better at and data structures that it's less good at.
Speaker 1:Yeah. And I think that it just to the, like, how you kinda think about how to phrase some of that. And and it I guess, interesting about your, like, less effective approach versus more effective approach. Because I think that it is really important to let, you know, those that are kinda coming to, I'm gonna I'm gonna take on a bunch of change with this new language. And to know that it's like, this does not invalidate your your previous experience, and this doesn't invalidate what you've done.
Speaker 1:And to the contrary, it's like you wanna bring some of that with you, but you need to, like, kind of there's some of that you're gonna need to leave behind or at least phrase differently, things like the w link list. But then there are other things that I think are gonna be really valuable. And I think one of the things I like about Rust is it does take from a bunch of different languages in terms of, like, it borrows wherever it can, I feel? And when the good things are good actually. What's that?
Speaker 5:That's a pretty good rest pun.
Speaker 1:The but I think that that's really important. And I I that that I think is part of why, you know, you're gonna find things, whatever language you come from. You're gonna find things like, okay, there are things here that actually this actually makes sense. Someone was here before me that had my same disposition and has left something that's added to the language that I am delighted by. And I think there's a, like, there's a lot of that stuff, but you gotta get over that initial hump to get to it.
Speaker 5:Yeah. I I initially underestimated the fact that for a lot of us, particularly those of us who have been doing this for decades, the the, adopting a new language is not an intellectual argument. It is an emotional argument and you have to approach it as such. People will take it very personally. People will identify with their language even if they don't realize they're doing it.
Speaker 5:And I should have seen that coming because I see people in the rest community doing the same thing. So we all do it. So you have to be careful attacking c to make sure that you explain that, like, no, you're not bad for writing c. Like, I've written a lot of c. I still do it from time to time, but, like, here's a different tool you might consider using sometimes.
Speaker 1:I also think that, Rust will make you a better c programmer. It'll definitely make you a a more frightened c programmer, speaking for myself.
Speaker 5:Rust made me the world's most annoying c plus plus code reviewer, to be perfectly honest. This started to be a problem at Google. Like, if once you are reading people's structures and and like back annotating the lifetimes that you would need to express to do these things in Rust, I don't know. I the the number of aliasing bugs that you can find reading an average code base is quite high and or potentially I
Speaker 2:could, I could imagine you saying, well, how do you know that, you know, that this operates in this particular way or has this particular lifetime? And those arguments probably ending with, because I said so, or because I'm pretty sure that that's true enough already, Cliff.
Speaker 5:Yeah. So the review tends to end with, well, can you please mention that in the comment on the function?
Speaker 1:Yeah. Well, and it's I mean, it's another reason to, like, get and I think that it's also just valuable to get out of to try other systems no matter what. Like, should you go do, to implement new languages and to try out different things, try out different systems. Because if nothing else, it just it keeps it it tamps down some of the fear associated with tech tribalism. And I think when that fear begins to feed on itself, that's when you get to Yeah.
Speaker 1:I think you just get into a bunch of really bad behavior. It's just not constructive. That's that's
Speaker 5:when things get gross and we don't make progress as a trade. We don't make progress as an industry when we're too focused on that. And Yeah. I see a lot of people in the rest community criticizing c plus plus who probably don't have significant C plus plus experience. And I think it would probably be really helpful for a lot of these people to go spend some time writing some serious C plus plus Like, which might sound like a weird recommendation for me, but like C plus plus has things to teach you.
Speaker 5:Rust has things to teach you. I don't know that you should write C plus plus in your avionics firmware or anything where it could kill people. That that's my, you know, that's my well known bias, but like, go learn C plus plus go learn Haskell, go learn Erlang. Like these all have things to teach you. And frankly, Haskell will make you a better c programmer.
Speaker 5:I don't know how, but it will because it'll stress your brain. So go play with C plus plus and see what you bring back.
Speaker 3:One of my favorite quotes is from Guy Steele when he was doing an AMA at PLDI. I wanna say it was 2020 or 2021. It was one of the ones that was virtual during the pandemic. And he just had this one small quote that was, I love all programming languages. And then he went on to follow-up to say that, you know, there's too much, not like dunking, but just, you know, folks and communities like to kind of, you know, go back and forth.
Speaker 3:And he thinks it's a real shame because there is something regardless of your personal feelings of a, you know, insert any language, you can there's always something to learn from that language, even if it is a language that is sunset, even if it's a language that you would never use to solve whatever problem that you're currently solving. Like you can learn something from every single programming language and, like, we would be in a better place if we did more like trying to understand what are the superpowers of this language versus, like, why my language is better than your language. And I think, like, that is like my personal, like, ethos is that I don't think folks should go and learn, you know, insert language, APL, Haskell, whatever, because they should go and, you know, convince their company to start using that language. But there are things to learn from every programming paradigm. And one of my favorite tweets is by Ben Dean, who's one of my favorite speakers.
Speaker 3:And he has this tweet along with a blog that says everyone should go and learn one of the following languages, like from this paradigm. And like small talk for OOP, you know, Haskell for functional programming, APL for array programming, Prolog for logic and etcetera, etcetera.
Speaker 1:No, it's all like spring processing.
Speaker 3:Yeah. His, his point being that, like, I'm not telling you to go and learn this so that you can tell your company to switch. I'm telling you to go and learn it so that you can learn how to solve problems in that paradigm, and that will make you it will enable you to put tools in your tool belt to then use those tools in whatever language that you use day to day. And, like, if you if you know c plus plus going and learning, you know, Zig or Rust is not gonna teach you as much as going and learning one of those other languages from a different paradigm, which, I I loved I loved that tweet. And I just, you know, I wish programming communities would would act more sort of in line with that.
Speaker 5:Yeah. I forget the term. I think it's disdain culture, but there's a there's a thing that a lot of us in the Rust community historically tried to avoid and not necessarily succeeded. But the notion that you can like a thing without having to be shitty toward its competitors. Like, you can like c plus plus without having to dunk on Rust.
Speaker 5:You can like Rust without having to dunk on Excel spreadsheets. You can work c plus plus. Right? And for systems programmers in particular, for the people that I mentor, one of the things that I recommend is that they write a 4th implementation, like, from bare metal. And I explain it as the 4th and particularly a hand rolled 4th implementation, it's like a lightsaber.
Speaker 5:You should build 1, you need to build 1 to sort of fully understand your trade and then hope that you never have to use it for anything.
Speaker 1:I boy. So when I when the 4th interpreter comes out, I've got this kind of image of you, Cliff, as Obi Wan with the with your with your 4th interpreter. That's yeah. That and when and I think implementing a 4th interpreter as well with that I mean, that's something that everyone can go do, and it's it's very I mean, it's it's also educational about why 4th has been used, where 4th has been used, because, yeah, you can implement a 4th interpreter in not much memory as it turns out. Well, this is, I think this is a great note to end on, Connor.
Speaker 1:I I this is, I I I think we we have settled the beef between our 2 podcasts. As you say, it's good for ratings. I feel that that but this has been, a lot of fun to have you on, and I I I think that folks should check out your podcasts. It's not just ASP, but also the the, it's a Raycast. Right?
Speaker 1:It's the other Yeah. And then I think I I kinda gotta have you back on to talk about more of those 70 podcasts that you find. If you find good podcasts, definitely, point us to them. We've got obviously folks here that are also, podcast listeners. So, would would love to love to hear that your recommendations there.
Speaker 1:But I just think that you're, I mean, I think getting out of your comfort zone, learning about different communities, learning about the kind of the the shared history of the domain, I think all of these things are really, really effective for us as as a domain, as a craft. And, that's the beef is settled, and I think we all learned how to settle beef in the future. If I may give a quick quick plug, Adam, for in the in the vein of arguably not settling beef, but stirring some shit up, I'm glad to talk at p99 Conf on Thursday. This is a free online conference. We had that great conversation with Kelsey Hightower on, corporate open source anti patterns, and I'm giving an update to that, and then hosting a panel, with, Adam Jacob and Ashley Williams, who are regulars on the podcast, at p 99.
Speaker 1:So that's gonna be on on, this coming Thursday. And if you hopefully, if you're listening to this with enough time to attend, you can, join us live. And, that will I'm not sure that will be settling beef. I think that's No.
Speaker 2:I think that's gonna be the opposite, but but, yeah, it was a brief moment. It was a nice moment we had there.
Speaker 1:It was a nice moment. Now it's time to go, to go pick some bites with some bad actors out there. But, no, that it's I I think that there's some things that need to be said. So looking forward to that, and, Connor, thank you again. Cliff, thank you, for for joining us.
Speaker 1:Great to get your wisdom and, excited to remain a listener to ADSP. It's really terrific stuff.
Speaker 3:Yeah. Thanks thanks for inviting me on, and also continue to do this. This is I hope that this serves as a, what do you call it, A mold for, you know, other companies that potentially are having meetings that there's no reason they couldn't hit a record button and put them out. It's honestly not as much work as folks would think. And, this is the first of its kind.
Speaker 3:I think that, you know, if other companies were doing this, it would be, you know, awesome for folks that don't work at that company to be flies on the wall for those conversations.
Speaker 1:Yes, please. And please point Connor and us to it because we'll, we'll be fans of your podcast too. Absolutely. Alright. Thanks everyone.
Speaker 1:See you next time.