Algorithms + Data Structures = Programs - Episode 223: Is C++ Dying? II

Episode Date: February 28, 2025

In this episode, Conor and Ben chat with Tristan Brindle about the recent C++ London meetup, the future of C++ and safety in C++.Link to Episode 223 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: Twitter | BlueSky | MastodonBen Deane: Twitter | BlueSkyAbout the GuestTristan Brindle a freelance programmer and trainer based in London, mostly focussing on C++. He is a member of the UK national body (BSI) and ISO WG21. Occasionally I can be found at C++ conferences. He is also a director of C++ London Uni, a not-for-profit organisation offering free beginner programming classes in London and online. He has a few fun projects on GitHub that you can find out about here.Show NotesDate Generated: 2025-02-17Date Released: 2025-02-28Contracts and Safety for C++26 : An expert roundtable - C++ LondonADSP Episode 150: Is C++ Dying?C++ Weekly - Ep 400 - C++ is 40... Is C++ DYING?https://plrank.comhttps://www.tiobe.com/tiobe-indexIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

About the whole safety in C++ and the future of C++ and do you think it has one? Should we just let it die? Should we just go, well, you know, C++ has had its time and now we should move on to something new? Or do you think we should pursue trying to turn C++ into a safe language? Conor, what's your feeling on the matter? Welcome to ADSB the podcast episode 223 recorded on February 17th, 2025. My name is Connor and today with my co-host Ben, we continue our chat with Tristan Brindle. In today's episode, we chat about the recent C++ London meetup and whether C++ is dying or already dead. Should we switch to C++ London because you guys were both there and you sent me a photo? Oh that's right. Yeah. Yeah. I had FOMO. I was I I mean I should have figured that there was

gonna be a meetup and Ben would be there and then you guys would bump into each other. Well, I only looked it up. You know, I planned my trip to England for the end of January and like a few days before I was due to go, I'm like, Oh, maybe I should look up and see if there's a something happening in the London meetup. And as it happened, a huge thing was happening. And there was like everyone flew in for it. It was the biggest meetup like in the history of the event,

because it was a very kind of special occasion, because it was Bloomberg had organized this panel of, was it six or seven experts on the C++ contracts proposal to sort of come in and do a Q&A all about contracts. And it is recorded. Link in the description for those that were not able to attend in purpose. To attend in purpose. To attend in person.

You can go click a link. I think it's like an hour and 40 minutes or an hour and 50 minutes or something like that. And I did hear Ben's voice on the mic at some point asking a question. I do not recall the question, but I do remember hearing your voice. I asked the question about whether contract handlers, there's a way with contracts to install

a user defined handler for contract violations. That's the way I was looking for. That is, I asked whether that was possible at compile time. It is not. It is link time only. So it's a runtime thing. Although everything else about contracts pretty much can work at constexpr time as well. That is the one part that unfortunately can't.

And the implications of that are that you can't entirely do contract checking at compile time? You can do contract checking at compile time, but you can't have a user defined violation handler. I see. So I mean, I'm guessing that you were hoping that you could do some kind of custom injection of some, I don't know error message or Well, if you can if you could do that a compile time it would mean that you could

Effectively do user formatted compile time warnings Yeah, yeah You do some ASCII art in there or something if you really wanted to Yeah any any or something if you really wanted to. Well, if you wanted to, yeah. Yeah. So I mean, people can go watch the talk, but any behind the scenes chats or gossip that you guys can share with the listeners of before or after, or was it just, people showed up, people left?

I think about gossip, I mean, I'm not sure if, I hadn't public that to any of my London friends that I was coming. I had signed up because, you know, signing up for meetups is a good thing to do because it influences, you know, the organizers know how many people are coming, what the kind of food and drink situation is, that kind of thing. So I had actually signed up, but I was signed up number 120, whatever, I don't know. I was down in the weeds. It wasn't like I signed up first so everyone could see that I was coming. So I just rock up and I see Gashper and Gashper's jaw drops onto the floor and he's all excited and waves at me

and then Tristan shows up and it's a good time. Gashper's like Tristan, Tristan, have you met Ben D? And the very first thing I said was, what the hell are you doing here? Which now I think about it, I probably could have been a bit friendlier, Ben, so sorry about that. But what I meant was,

it was a bit of a surprise to see you. No, you know, that's how British people treat each other. That is totally friendly. Yeah. Yes, yes. Man of the moment, Gashper, who is gonna be,

seem to be one of the most important people in C++, I think, has been appointed editor of the Safety White Paper. I don't know if you've seen that. Ah, right. I have not seen that. Along with Herb, they're going to... Between the two of them, I believe.

Interesting. So that's going to be... Actually, let's go on a tangent. I'm going to be the host for a moment. I'm going to ask you two questions. Or a question about the whole Safety in C++ and the future of C++ and do you think it has one? Should we just let it die? Should we just go, well, you know, C++ has had its time and now we should move on to something new? Or do you think we should pursue trying

to turn C++ into a safe language? What do you all, Connor, what's your feeling? I want Ben to go first. I mean, this is, this sounds like it's a revisiting of episode 150 when we, Bryce and I sub-podded that other podcast and they were all like, it's dead, blah, blah, blah. I think the podcast episode was, is C++ dying? So I don't know if we're going to call this one,

is C++ dying 2.0 or addition, addition two? I'll let Ben go first. Well, I have opinions. I have observations. Obviously, C++ isn't dying for the same reason that COBOL isn't dead. It's past the threshold of immortality. That's a trivial thing to say. But with safety in particular, it seems like no one's realized the impact of the current geopolitical climate on the safety conversation. Who is now going to fund work on safety? Nobody has an incentive to do so. The US government is deregulating everything. You know, there is simply going to be no pressure from the US government anymore for the next at least four years, probably longer, to do anything with safety. That's the sad fact. So you know, even if C++ gets safety in some form, there is no incentive for any tech company to work on it.

The implementation of said safety will not occur to a first approximation. You know, we're seeing already tech companies just changing things in response to the current administration. Now, you know, this doesn't take into account Europe, the European Union, which is a force for good maybe in this. We'll have to wait and see but I certainly think that the current climate has not only taken the wind out of safety but even reversed it, very sadly. We don't have to be happy about that, of course. So that's just an observation that I have. It's very similar to what happened. You know, a lot of people, again, we can sort of learn from history. If you are old enough to be working professionally around 2000, you may remember which some of our listeners no doubt were.

I have friends who were working at Microsoft then. Microsoft was being investigated for antitrust by the Department of Justice. Microsoft was in potentially quite a lot of trouble. They were talking about splitting up the company, all those kinds of things. When the Bush administration came in, it pretty much went away overnight

from what I heard from people who worked at Microsoft at the time. And the same thing is happening here. Safety has gone away overnight, or at least the incentives to become safe in the US have disappeared overnight. A very good observation. But a part of my, there's a voice in the back of my head that says even though that's the case it's probably not going to Halt the committee's desire to make progress in that space because regardless of the current administration in the US

long term it definitely seems like that is the the Long-term it definitely seems like that is the the the trend So even if we do take a four year break or an eight year break from the incentivization to do that My guess is that in two decades from now? It's gonna it's you know gonna the incentivization will Rematerialize at some points and well, I certainly hope so and don't get me wrong. There is still a moral imperative here Yeah, there is still a moral imperative here. There is just no structural financial imperative within society at the moment. Yeah. I guess in terms of like the my take on like dying or dead, like, you know, I agree with Ben in that

there's no such thing like C++ is dead. Whenever you hear people say that, I think they're playing fast and loose with that word. The question is, is it now on like a downtrend? Like has it peaked? And like over the next 50 years, pending that the AI singularity doesn't wipe out the planet or some other catastrophe, What's going to happen?

And from my point of view, there seems to be so much wind behind safe languages, primarily Rust at the moment. Like, I listen to a ton of other programming language podcasts, and I'm not really a part of those communities per se, maybe Python a little bit, but there's so much tooling and like transferring of tech written in a certain language to being written in Rust. And you never hear it happening to being written in C++. All these new JavaScript like runtimes,

like Dino, et cetera, Bun, all being written in Rust. All this Python tooling, you know, rough UV being written in Rust. Like all Python tooling, you know, rough UV being written in Rust. Like all of this like tech transfer that's happening to get these 100X speed ups from being implemented in Python or JavaScript or some other language and then re-implemented in a systems language, it always happens in Rust.

And I get the sense that like new projects in this kind of vein always happen in Rust. That doesn't mean that like C++ is going anywhere. I think Jason Turner, he had a C++ weekly video where he highlighted all of the massive software programs, Word, LibreOffice. He goes through just a ton. And they're all written in C++. And if you think about currently, there's this joke that like oh you should

You know when we're in the age where you should never need to manually manage memory, which is ridiculous I don't know if it's an XKCD or it's some like quote or whatever, but it says that like every single GC languages GC is implemented in C++ So it's like the ability to not use manual memory is due to manually managed memory and So I don't think C++ is gonna like it's according to rankings, you know rank number five or six depending on The language ranking. I don't think it's number two the new T-o-b-t-o-b. That's the worst index of all

It's apparently this is like people have just been Are you kidding me? worse index of all. Apparently this is like people have just been Are you kidding me? I'm pulling it up right now. TIOB stands for the importance of being earnest. The irony not lost there. Look at that, folks. Python number one, C++

number two. But let me, let me, you know. Highest position since 1995, I read somewhere. Fortran is number 11. Delphi slash Object Pascal number nine visual basic number 10 typescript doesn't even make the top 20 I think it's ranked like let's find it folks 38th and on every other single measuring site or ranking site it's a top 10 language and I think we we've got Prolog is making a comeback. One of the fastest growing languages at number 20. And and so just like I have, I don't know what is up with this site,

but I actually it's still included. The link is still included on my PL rank dot com site. But I have disabled the ability to include it in the average because I just have checks checkboxes to, you know, calculate the the average because I just have check boxes to calculate the weighted average. I've excluded it. You're no longer able to include it because I think it's such a bad site.

And so whenever I hear podcasts linking to this, and don't get me wrong, I used to look at this site all the time because I see rankings, I see logos, I go, ooh, very nice. But then when I started noticing the changes from month to month when this gets updated I was like what the heck is going on here?

Like the fact that TypeScript is 38th and that prologue and Fortran I'm not saying the Fortran isn't potentially a top 20 based on some metrics, but I mean It's probably not higher than TypeScript is all I'm saying. So but I guess Asterisk it is number two according to TIOBE. But yeah, I don't think it's going and it's not going to drop out of the top 20 in the next 30 years. I don't think it's going to be still one of the most popular languages and I still think there's going to be if you look at the number of jobs open per language, it still ranks one of the highest and I don't think that's going anywhere. The question

is is like the momentum, you know, like and I think we're gonna whether it's Rust or some other language. Yeah, I definitely think the momentum is going to be switching to and honestly, I'm not even sure it's safety to be honest. I think the tooling is my number one recommendation to the C++ community. If you can replicate the Rust up experience for C++ so that I don't need to go manually configure clang format, clang tidy, include what you use, cpp check, all this stuff. Rust up just does it for you. Not only does it do it for you, it initializes a git repo with your git setup and you can just immediately go git diff. It's amazing. I think 50% if not more of the reason Rust is doing so well is because of its tooling experience.

It's not because it's a more pleasant language or whatever. Like safety is great, but I honestly, you know, for research work, I don't care about safety. I care about being able to prototype quickly, right? Not having to say stuff. We have to recognise also that we are talking about the sort of the pyramid here in terms of the privilege of being able to write in a desktop environment or in a server environment or in an environment that can support these kinds of things. One of these days, in one of my talks, I'll put a pie chart, which will be like number of processors in the world, and it'll be like desktop and server processors versus embedded processors. And the pie chart is just going to be one color.

It's going to be embedded processors because there won't be enough resolution to display the number of server and embedded processors in the world. Have you tried counting the embedded processors just in your room that you're in right now or in your house? Well let me tell you that every every desktop or server processor contains within it dozens of embedded processes. So that alone is going to mean that you know and programming embedded is still often done in C not even in C++.

I do it in C++ and it certainly is possible in C++, but many, many people are still working in C and we still have to work in assembler sometimes. The idea of programming embedded in even Rust, let alone JavaScript, TypeScript, maybe another language, a safer language. We are a long way from that at the moment. Rust, Rust had, the reason I don't think Rust is taking over there anytime soon is, I mean, there are initiatives to do Rust on Embedded,

I'm aware, and there are, you know, and Embedded is getting more capable, right? Embedded doesn't always mean bare metal. It might mean some embedded Linux distro, right? And in that case, maybe Rust is viable. But at the moment, C++ and LLVM are the only things that have a defined memory model. Every language that uses LLVM inherits the C++ memory model because it's what LLVM provides.

And when you're doing work with interrupts, when you're doing that kind of work, you need to be able to reason about the memory model. That's one thing. At a higher level, when you're programming libraries, C++'s killer feature is variadic templates. Absolutely no doubt in my mind. I cannot understand why Rust is not scrambling to get variadic generics.

Apparently they've looked at it, they've decided it's not high priority. It is the single biggest feature for writing libraries. It is the most powerful feature. I contend. I mean, I know multiple people that have said that's the reason they prefer C++ to Rust is that they aren't leaving a language for another language that doesn't have variadic generics. And like I think even on Oxide and Friends, which was the podcast that we subpotted where they had a couple of people saying C++ is dead, they had one of their employees at Oxide like speak up and say that like, well, from a library implementer like point of view,

it is actually quite painful trying to do some of the stuff that's possible in C++. And I think he might have even like the tuple implementation example of doing this kind of stuff. Sure, we have macros and you can superficially get the same kind of thing, but that's not idiomatic Rust. You don't want to be in trait land and iterator land and then want to do something that's variadic and then have to reach for an iZip macro. It's just it's awkward. A lot of people don't even know it's there. And that's the solution

right now. I've asked a few Rust programmers, if you want to zip over a couple different sequences and then unpack it, how do you do that? And they're like, oh, well, you have destructuring in the parameter list. So I can just destructure a tuple where the second element is a tuple. And so your destructure is just like paren, a comma, paren, b comma c, end paren, end paren. It's not super elegant, but it does work. And the more you try and scale that, the worse it gets. But that was the answer I got.

And the individual said, honestly, I acknowledge that C++'s solution is superior here. But that is something I'm willing. I'm not an implementer. I'm just consuming this stuff. And that nicety is something I'm willing to give up. But from an implementer's point of view, it's not just a syntax inconvenience.

It's a tool that you no longer have to build your library. And I think he mentioned that like this was a huge gap that like a lot of people don't notice because a lot of like, the majority of folks are app, you know, writers, they're not library implementers. And so unless if you're talking to a library implementer, you're not really going to hear about this kind of missing piece, right? It's funny you should say that because I would, I mean, it's true, but everyone writes functions, everyone writes libraries because we write functions, we write APIs, right?

Regardless of what we're doing. Very few, there are very few people who don't write functions. So regardless of whether you're an app writer or a library writer, I think variadic generics are super, super powerful. Yeah. And that's my, you know, I have a bias here. And my bias is that I haven't written a non-template in about six years professionally and I haven't

written a non-variic template hardly in most of those six years so there you have it. What's your opinion? We've voiced ours now. We'll flip it back and now we're the interviewers again. On varietic templates? No, just everything. Is C++ on its way to dying?

Is it only in a second kind of winter as was the 2000s and we're about to get C++ 26 or 29 and it's gonna be a second boon, you know a golden age of C++ Well hmm, well I agree with you that There is just too much C++ code out there for it to ever truly die like it it won't whether C++ code out there for it to ever truly die like it it won't. Whether... The thing that might happen is it just loses mindshare. Like people just...

The young people when they're learning to code they just think of C++ as an old language and they don't want to you know start using it and it becomes harder to hire C++ programmers because the ones that are there are starting to retire and people just move away from it for that reason. It just loses mindshare and in the end just sort of fizzles out for that reason. I think that's one of the dangers of, dangers if that's the right word, one of the potential futures just because I think you see it a lot already is that if I can generalize of younger coders like people who are just getting into it it seemed to gravitate more to more to rust than C++. It's seen as you know trendier if you like. So even outside of the safety thing that's that's something that could

happen. In terms of safety yeah Ben you're right that the regulatory pressure might reduce. Companies of course, they always care about the bottom line. And if safer languages mean they're going to face fewer vulnerabilities, things that could cost them money, you know, that might be a reason that they choose to do it anyway, even outside of regulatory pressure. So, yeah, I would like to see a safe version of C++. I support kind of the goals that Sean Baxter had with Circle of coming up with...

It is really the subset of a superset thing that Herb and Bjarne have been talking about for a few years now. We want to expand the language with safe facilities and then have a safe subset that you can do most of your everyday programming in. I think that would be a good future for the language, but whether we can get there, I don't know. It's incredibly difficult. Yeah. And I mean, the committee, even if we do get there, it's going to take, I mean, stuff that supposedly a lot of the committee agrees on, it still takes up taking like a decade to

get in. Yeah. Yeah. And then it's like, it's the whole, the backwards compatibility is always the difficulty with C++. Even like you were saying with the tooling being problematic, but with any new language, or nowadays anyway, because people have learned the lesson, whenever a company comes with a new language, they will have, it will come with a build system, it will come with a linter,

it will come with a source code formatter. And so people just have this from the start. And we could probably have a similar experience to what you get with cargo and Rust-up and that stuff. But it would mean that you would have to lay out your files in a particular way, and you'd have to give them a certain file extension or whatever. And the C++ people are hell no.

I want things to be standardized, but I want you to standardize it my way. So it's kind of a bit of a problem. Everyone wants nice at ease, but as long as they don't have to change what they're doing. C++ supports such a wide range of hardware that it is very diverse in terms of needs. I saw just this weekend, just last week, the C++ committee was meeting. Making a byte eight bits for C++26 was just dropped. A byte is not necessarily 8 bits because presumably there are hardware platforms out there that preclude us making that determination. So C++ is extremely supportive of diverse hardware.

Yes, I had no idea that these platforms still existed, but apparently they do. From what I... So I don't know anything about this really, but from Google searches, I see that there is DSP hardware that is specialized to work with even 12 bits, 14 bits, 16 bits, where the tool chains just treat that size as their byte, I guess. And yes, why not? If you have a specialized piece of hardware that does one job and it just effectively has one data type to work on, then why would you spend the silicon to make bytes addressable, to make 8 bits addressable if you only ever work in 16 bits

I guess like I say, I really know nothing about it. So that's just Well, I'm surmising. All right. Do we want to put a bow on this is C++ dying second edition conversation any any final thoughts on Don't call the episode that I feel bad. I feel bad now slice of this conversation. Any final thoughts on? Don't call the episode that. I feel bad. I feel bad now. I was just curious about what you two thought. I don't want to... You gotta put these catchy titles though. C++ is still fun, right? We shouldn't lose sight of the fact that learning languages is fun. Learning C++ has a lot to offer. And I'm a big fan of languages in general.

Different languages have different things to offer and the reason to learn C++ in 2025 is the same as it's always been because it's because you learn things about how languages work, you learn things about how computers work because it's fun. Yeah. APL is fun too. I would argue more fun, but that's okay. I didn't say it wasn't. I didn't say it wasn't. That's just a slight APL.

I can spell iota in a single glyph instead of, what is it? Three plus two colons for the namespace plus is nine, plus you need the parentheses and everything else that comes with it. But, you know, there's another reason I love C++. It borrows heavily from APL. All the numeric algorithms come straight from there, inner product, adjacent difference. And APL even gets, not only does APL get mentioned

in from mathematics to generic programming, there is a line of APL code in from mathematics to generic programming. There's a whole page where Stepanov references both Kenneth Iverson's 79 Turing Award paper notation as a tool of thought and John Backus's Turing Award paper from the year before in 78. Can von Neumann languages be liberated from the von Neumann style? Yes, where he introduces the FP language, two of my favorite papers.

And they're top five. I'm not sure if they're top five, but fantastic. They get referenced in like the same two paragraphs. And then I think he shows an example of a plus reduction. And so there's, there's APL, you know, if you weren't convinced by the passion that Stepanov has for the stories of mathematicians, you know, go read it for that one line of APL code. All right, we will, we will wrap up. I think that's episode two 23. And now we're starting episode two 24. Be sure to check the show notes either in your podcast app or at adspthepodcast.com for links to anything we mentioned in today's episode as well

as a link to a get up discussion where you can leave thoughts, comments and questions. Thanks for listening. We hope you enjoyed and have a great day. I am the anti brace.