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

Episode Date: October 6, 2023

In this episode, Conor and Bryce talk about their personal thoughts on the the state and future of C++.Link to Episode 150 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachShow NotesDate Recorded: 2023-09-25 Date Released: 2023-10-06CppCast Episode 367 - SoagenOxide and Friends Episode 44 - Books in the box reduxAlgorithms + Data Structures = Programs by Niklaus WirthElements of Programming (Free PDF)Beautiful C++: 30 Core Guidelines for Writing Clean, Safe, and Fast Code by Guy Davidson & Kate GregoryKeynote: C++ Horizons - Bryce Adelstein Lelbach - ACCU 2023Experimenting with Modules in Flux blog by Tristan BrindleADSP Episode 111: C++23 Ranges, 2022 Retro & Star WarsC++ on Sea 2023: C++ and Safety - Timur DoumlerIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusic Creative Commons — Attribution 3.0 Unported — CC BY 3.0 Free Download / Stream: http://bit.ly/l-miss-you Music promoted by Audio Library https://youtu.be/iYYxnasvfx8

Like, concept is a concept in C++. Whoa! And, yes. There's a thing called concepts? There's a thing called concepts. Yeah, I think there's not actually that much going on currently in the reflection study group. I think the work there has kind of stalled, I think.

And I'll make a bolder statement. I'll be very surprised if any major language feature ships in C++. Period. be very surprised if any major language feature ships in C++, period. Welcome to ADSP, the podcast, episode 150, recorded on September 25th, 2023. My name is Connor, and today with my co-host Bryce, we talk about the state and future of C++ and our opinions on whether or not C++ is dying. All right, folks, episode 150. We're almost at the three-year anniversary of ADSP the podcast and I'm excited. I'm excited to record this podcast

because I think it's gonna do well on the socials. I think people are gonna have a listen. Welcome to the new listeners. My name is Connor. I'm here with my co-host Bryce. We both work for NVIDIA. We are both, I don't know, I kind of consider myself not a former C++ engineer, but I work in research now and I get to code in whatever I code in. And I am a huge Python fan now. I don't really write C++ or Rust code. I write Python code that writes C++ and Rust code for me because that's way easier. And we'll talk about that in a future episode when I can talk about the projects that I'm working on. But Python is amazing. And while we were on our quote-unquote four-month break, we weren't really on a break, but we had recorded a ton of content.

I believe it was sometime in August I was listening to CppCast, the number one C++ podcast. We're number two. And I'm going to queue it up. Actually, I think I've got to share my screen. I'm going to go. We're number two. And I'm going to queue it up. Actually, I think I got to share my screen. I'm going to go with a distant number two. I don't actually know. I mean, based on number of subscribers, yes. But based on number of monthly views,

we're actually pretty close to them. We're actually pretty close to them. All right. Episode 367 from CppCast, where they are interviewing Mark Gillard. I apologize about the pronunciation. And we're going to hear from Timur Dumler. We're just going to listen to a few seconds here. And this is on the status, because this episode is talking about a library that is, I think it talks about SOA versus AOS, which is structure of arrays versus array of structs, and a library that is called Soagen. And they're talking about reflection, and then at some

point, Timur opines or comments on the status of reflection. And actually, a few minutes earlier, Bryce, you get mentioned because of your ACCU talk, which I believe was the, you know, top three features that you're looking forward to in C++26 or C++ of the future. Anyways, Bryce, take a listen. And I will cut this in for the listener as well. Don't worry, I'm not going to leave you hanging. But yeah, I think there's not actually that much going on currently in the reflection study group.

I think the work there has kind of stalled. I think they kind of ran out of funding for like to keep working on these papers and compiler forks or something. I don't know. I don't think there's much going on there at the moment. Unfortunate. All right. You heard that, Bryce? Yeah. I mean,

I think that's not inaccurate. That's not inaccurate. So, you know, that's the first clip. And this is the first, this was the first little seed that got planted in my mind. And I thought, uh-oh. I mean, actually, that's not true. There's been a lot of seeds from before that. But the first time on a podcast.

And then fast forward a couple weeks. I, of course, am doing the, you know, well, I wouldn't say it's the chore. I am enjoying a bunch of podcasts right now. Two of them, Software Unscripted and Oxide and Friends. I have been going back to episode zero and watching or watching, listening to the entire backlog as one does. And on episode 44, episode 44, entitled Books in the Box Redux, where they go through and they talk about all these books that are worth reading. What do you think the first book they talk about is, Bryce? ADSP.

That's not a book. Yeah, Algorithms and Data Structures Post-Programs is a book, famously. That's why we hit the podcast. That's classic, yes. Elements of Programming. No, the book that they talk about is Beautiful C++. Oh. Which is a recent book by a couple of well-known people that are going to get mentioned in this.

So we're going to listen to three minutes of this podcast. I think it's one of the rare C++ books that I have given my endorsement to, although I have not read it. All right, Bryce. Well, strap in, strap in, because this is good. We're going to listen to a minute and then we're going to skip ahead and we're going to listen to another couple minutes. So here we go. I mean, have you looked at modern C++? Yes. It's called a brush. I mean, it's like, why would you spend time on modern C++? No, no, no. I mean, that is the punchline,, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no But seriously, every page of it strikes me not as beautiful, but as disgusting and as basically an advertisement for Rust. Like, yeah, C++ got all these things wrong.

All of the defaults made sense in the Jurassic era, but now here we are. And so the defaults don't need to all be wrong. The defaults can all be right. And it is called Rust. But it has definitely given me an appreciation for programming languages generally and for Rust specifically as a reaction to some of the shortcomings of Suplug. So look, look, okay.

All right. Wait, wait, wait, wait, wait, wait. No, no, no, no, no, no. We got two more minutes. We got two more minutes. I got some thoughts. Look, I like to shit on C++ as much as the next person. And I'm a member of the committee. Are you still a member of the committee?

Until my recent retirement, I was chair of the Library Evolution Group. And I feel like that gives me... But the thing is, if you're going to shit on C++, I feel like you need to have some credentials to do so. Like, I've been doing C++ for 10 years. If I want to talk shit about C++, I feel that I am qualified and have earned the right to do so. Some dude talking about modern C++

and how dynamic cast, which is a thing, but not a thing that you really use that much in modern c++ and how dynamic cast which is a thing but not a thing that you've really used that much in modern c++ and unique cast which is not a thing you know maybe you're not maybe you're not qualified to be talking talking out your ass not not the reaction i expected and we will get to your resignation as chair of lube, but we're going to first, we're going to listen to another two minutes. Retirement, whatever. Same, same difference. We're going to skip ahead to the very, very different things. Resigning is something that you do when you're fed up with something. Retirement is something that you do when you're tired. All right. The next two minutes from Oxide and Friends episode 44,

Books in the Box Redux. And also, folks, go listen to the whole thing. There's a whole like 10-minute section where they talk about this book. It's fantastic. I absolutely love it. Here we go.

So Beautiful C++ to you is just like, this is why we should have Rust. This is not... I mean, it is a... I'd actually recommend it. I think it's an interesting book. Are they going to put that on the back jacket? I'd actually recommend it.

Raves to Adam Levithal. I do want to see if I can get... So the authors are Guy Davidson and Kate Gregory. And I would be very interested to see... And 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 such a shame. Because these are folks who really have nuanced, deep thinking on this very important language. This is not the disparage C++, but one that they are themselves ready

to acknowledge the burrs and the mistakes of. And I'd love to see what they think of Rust just because I feel like, seriously, every page is just more and more of an advertisement for it. And when you get into concepts, concept is a concept in C++. Whoa! And yes, I had not heard of that.

There's a thing called concepts? There's a thing called concepts that is a bit like a trait. But people are gonna like, big pillory for making that kind of gross analogy there. But it's for describing the characteristics of a template. The type T needs to obey these parameters perfectly. Huh.

Okay. All right. I got to say, people like this are the reason that people dislike Rust. And not like on a technical level. What do you mean people dislike rust and not like on a technical level what do you mean people dislike rust it's the number one most loved language in the right but there's a reason that that that rust has a has a reputation for um over the top uh evangelism and it's i mean like i just they i think they have a very uneducated take. And honestly, I think somebody saying, I don't have time to learn new languages is a very legitimate and reasonable take. If you're, if you're, in this case, the person in question is, you know, a very senior programmer at a game studio. Like, his day job isn't to learn new programming languages. His day job isn't being a programming language person

or a compiler person. His day job is, like, he has to make games, you know? Like, he's got shit to do. He doesn't necessarily have time to go and learn a new language, much less figure out how his organization's going go and learn a new language much less figure out how his organization's going to switch to a new language like that that's to to act like oh it's such a shame that that that these people won't open up their hearts and minds to new languages like come on no that that that is a bullshit um take and and that is like, it's making it sound like, oh, these people are, you know,

living in medieval times and refuse to change. I think it is not at all unreasonable to recognize that there is an inherent and large cost to learning and adopting new languages. In fact, that's why the barrier to entry for new programming languages is so hard. I think we've talked about this in the podcast before that, you know, a programming language really needs to be 10x better than its competitors on some angle. That's a theory that comes to us from Andre Al-Zandriscu. Like, well, why do you need to be 10x better for a programming language to be able to have a chance at being successful at breaking in? It's because it's so freaking hard to adopt new programming languages. Like, let's not trivialize that. You know, I don't have time to go and learn a new language.

And I'm a co-host on a podcast where we spend a good chunk of time learning new programming languages. We're all very busy people and learning a new language is not like a trivial thing that everybody can do, especially when you're like in the trenches, like building production software. So I think that there's plenty of ways to criticize C++ and promote the positive aspects of Rust, but I think that that is absolutely the wrong way to go about doing it. Anyways, I'm sure you had a point between... I'm not really seeing the thread between these two clips, so I'm going to let you continue, because I'm sure you have a purpose here.

Oh, no no this is fantastic I mean recall that at the end of episode 149 you said that you did think the answer to the question is c++ dying was yes but that is juxtaposed with your response to each of these well you said it's not true to say that reflection is stalled and the CPP. No, no, no. Sorry. I think I was pretty clear when I said that, no, yes, that's pretty accurate. Reflection is stalled. Yes.

And that is definitely a separate clip and really nothing to do – well, I'll say what they have to do with each other. But just to be very clear, yes, I think that Teamer's analysis was quite accurate. That's what I said. And by accurate, I mean that he said that it stalled and that the people who were working on it had kind of run out of funding and energy and time. And yeah, that's correct. That's what happened.

So yeah, I don't, I mean, I'll have to re-listen to exactly, and I'm not even going to know the individual's names because there's so many people that talk on Oxide and Friends. I know Brian Cantrell was one of the voices and he actually was a C and C++ developer from years ago but has just not used the language. Yeah well he hasn't been a C++ developer since like the 90s I'm going to guess. Look if they want to have a real conversation about the merits of C++, they should invite me on their podcast. I mean, okay, fine. But my – so I don't actually think they were trying to be – like when the individual that was speaking said that he wanted to see if either of the authors had opinions, I don't think he said like, oh, it's terrible that they don't have opinions on Rust.

They need to go learn Rust. I think he was just saying it's a shame that they don't have opinions because he was looking for them. And I... Yeah, I think there's a better way about expressing his message, a more nuanced way of doing that.

But I mean, I'm somebody who has a lot of hot takes too, so... Yeah, I was going to say, I mean... I just think my hot takes are better than, I mean, I was so thoroughly entertained, not just for the first 20 minutes of that podcast, but like for the full 90 because they end up talking about some other books that were fantastic at the end. It was just such an entertaining podcast. But I think in general, their point is that like Rust fixes a ton of the stuff

that C++ got wrong and looking at a quote-unquote... Yeah, but Rust also has problems as well. Yes, yes. Every language has problems. Let me finish my point. My point though is that reading or skimming through, I'm not sure actually to what extent, you know, he read the book, but reading like a modern C++ book, which is effectively like they took a subset of the modern guidelines and then bookified it with examples it's like coming from a language like rust is kind of painful to see like our workarounds and our guidelines for dealing with you know lots of corners of c++ that are basically like like, no longer a problem in Rust.

Like, I think their observation there is accurate, if not, you know, in your opinion, delivered in the best way. I thought it was delivered fantastically because I just want to be – like, when I was listening to that podcast, that's what I – I can't remember which – oh, when we were interviewing Rob while walking in Venice. And he was trying to be politically, you know, sensitive about what he said about Q and KDB+, and I was like, feel free to give hot takes, man. It's what drives ratings. And my point that is connected between the two is that I listened to that first one about how reflection has stalled, and keep in mind that that is one of the top three things that you were looking forward to. And when you add the two others on that list, one of the other ones is pattern matching with, from what I can tell, if you pay attention to the mailing, like, I would be very surprised if either reflection or pattern matching made it into C++26. I will make a bolder statement.

I will be very surprised if any major language feature ships in C++ 26. There you go. And I'll make a bolder statement. I'll be very surprised if any major language feature ships in C++ period. Like ever? 29? 32? Yeah. Alright. I can

see, I think there's more behind, or actually, instead of me, you know, opining on why I think you're making that, would you like to explain why you think that is the case? Yeah, I think that the committee has grown so slow, the committee process has become so slow and antiquated that it is, the cycles upon which we develop these major features, it's just so long now, and especially relative to a language like Rust. And the pandemic was very disruptive

to the language evolution part of C++ because essentially it was put more or less fully on hold for two to three years. And after you take a break for something for two to three years, it can be really hard to get it started again. On the library side of things, we didn't take a two to three year break. We forged ahead. We found new ways of working. We modernized our process. That happened to some degree on the language side of things, but essentially the policy was, well, we'll modernize our process. We'll work on things during the pandemic, but really we'll just work on the small things. And I think a lot of the major contributors and collaborators in C++ on the language side did not, have not accepted into their hearts and souls the fundamental tenets

and ideas and philosophy of remote work and asynchronous work. And that has made it very hard for us to really truly modernize how we operate. And a lot of people have disengaged. You know, they stopped participating during the pandemic and they haven't come back. And I mean, you know, if you're somebody who believes that, oh, the only way that we can work on the C++ is the special and unique language, that even though C and Fortran and COBOL and Pascal

and Rust and Swift and Python, even though all the other languages on the face of the earth have been able to figure out a way to evolve that's not required meeting in person three times a year. And that's the only time when we can do work. If you believe that C++ is special and the things that apply to other languages don't apply to C++, well, we're in an environment now where not everybody can go and fly three times a year to some remote destination to go work on this language. We've not really made it easy or possible or been mindful of remote participants in the committee process. And so we've created this environment where we've made it very, very difficult, especially in the current environment, to be involved in C++ language evolution. And this has greatly decreased, I think, the number of people that are involved. And also at the same time, we've lost a lot of contributors after the pandemic, people who have just chosen not to come back, and also people who have chosen to invest in other languages because they see the writing on the wall. So yeah, I think it's going to be a while before we ship major language features in C++.

And I don't know that the current process is going to work for us. And I think unless we come up with a new process, we may not ship major language features again. And I want to be clear about something here, too, that why do I think C++ is dying? I don't think it has anything to do with the particular technical merits of the C++ language. I think the number one thing that's going to kill C++ is the C++ evolution process.

Because at the end of the day, it doesn't matter where C++ is relative to Rust. Like, if you think about where the languages are, how good the languages are today, think about that as your velocity. That's not relevant. The relevant thing is the acceleration. And by acceleration, I mean the pace and the quality of the language's evolution process. Now, admittedly,

the Rust evolution process, it's got some problems. Rust has had a good bit of drama in recent years. But those have been problems that I would characterize as primarily political problems in the evolution process of Rust. And there are many languages that have political problems. However, the procedural and logistical aspects of the Rust evolution model are drastically better than C++. And so while yes, Rust and C++ both share some of the same types of political problems in evolution, which honestly any project is going to have political problems. And if you don't accept that as reality, you're not going to go far. But that's really the thing that's going to kill C++.

It's not that C++ is a worse language compared to Rust today, although I think there's certainly ways in which it is. The problem is, where is C++ going to be in 10 years from now? The problem is that you and I, two people who have prominent careers in C++, we both aren't confident that C++ is going to be able to ship any major language features in the next three-year cycle. And even if we did ship a major language feature in C++ 26, which is, again, three years from now, let's say that we shipped pattern matching and reflection in C++ 26, How long would it take before those features are deployed in compilers and people can actually use them?

It probably wouldn't be until 27, 28. That's like five years from now. If I go to my management... That's generous. I know modules was a different kind of feature, but it is 2023, and we still don't have like in a single compiler i know that there are varying levels and there's starting to be articles you know tristan had one on implement using modules but like it is not like a baked feature that people can just go use

regardless of compiler that they're using and so to say that we're going to be able to use a language feature in 27 after it ships in 26, I think is generous. And so the language features that ship in 26, we're not going to be using them until C++ 29 or 30. And if they don't make 26, which I think is pretty likely, I think they would make 29 at earliest,

we'd be talking like 30, 31, 32, 33. That's 10 years from now. Can you imagine all of the things that are going to happen in the next 10 years? Can you imagine all of the work that Rust is going to get done in the next five years, in the next 10 years? Can you imagine all the work that all these other languages, you know, I'm skeptical about the prospects of some of the various C++ successor languages, but certainly I'm not skeptical that none of them will succeed. I think probably something will come out of some of them. You know, can you imagine in five years where a language like VAL would be, where something like Carbon would be, where something like Circle would be. Think about all the stuff that could get done in five years. Think about

all the work that just Sean Baxter, one person, one guy, could get done in the next five years. And think in parent to the work that we're likely to get out of the C++ committee and C++ implementations. And that is the thing that's going to kill C++, is that the process has become so archaic and so gridlocked and so risk adverse that we've lost all agility and eventually everybody else is going to pass us. We haven't reached that point yet, but eventually we will. And like when I say we haven't reached that point yet, like, yeah, we do have a lot of glaring deficiencies. But those deficiencies aren't currently like 10x deficiencies. But we will reach a point where they really will be. And how do we solve the problem? Well, I think the solution is that we have to radically change

how we evolve the C++ language. Yeah, this is fantastic. So I had in a Google Docs a title, is C++ dying? And then eight bullet points. You basically filled in, I think, three of them. The first one was CppCast, where the quote about, you know, there's no progress being made on reflection, which obviously isn't great if you want to see reflection in the language, which I think is more emblematic of the fact of what you're talking

about is how the committee is not making progress on a lot of things that have been being worked, like pattern matching first showed up before C++17 as a proposal. It was baked alongside with variant. It's like variant and pattern matching initially showed up at the committee as one proposal. So now we are, you know, coming in on close to a decade if they come, if they show up in C++26, which we both don't think is going to happen. You know, fingers crossed, would love to see it, but don't think it's going to happen. So anyways, the point is, is that committee issues. Number five on the list was the Oxide and Friends clip, which is just highlighting that there are alternatives that for a lot of folks is just way more attractive than C++. You basically touched on number two and number six, where I

have written that, like, I know multiple people that basically don't attend committee meetings anymore, whether that's because of the pandemic, or it's because of other reasons. But I definitely know of folks that I've spoken to that are no longer engaged in the ISO committee C++ process for one reason or another. And I think that is showing in the lack of progress on certain features, whether that's in the language side or library side. On top of this, number six, which I think you kind of mentioned, you know, referenced, is the fact that I'm not even sure. I don't think Google would agree with this statement, but I'm interested to hear your take. My point is that Google is largely moving away from C++, or at least they're making a bet on Carbon to have this happen. And I think that is

not only, you know, impactful in terms of that they're trying to make a successor language, but also the people that stepped back from the committee was like a huge loss. Oh, yeah. We don't need to list off their names, but there are a ton of very, very bright folks that are working on Carbon that previously used to spend a lot of time at committee meetings running different groups. And those folks, they have been replaced by other Google employees. But, you know, I think it is... Have they? There are a lot less people

from Google on the C++ committee today. Yeah, I do know that there are people that still from Google that go to committee meetings. But yeah, I think the numbers that they used to send and also to like the people with the depth of expertise, and that's not to say that the new people that are going, because actually I'm not even super familiar with them. But just like, you know, for instance, like one name, Richard Smith. I think it was a huge loss to C++ when Richard Smith stepped back and started working on Carbon. Anyways, and there's a couple others. But just in general, I have started to see this like picture form over the last year or so. And I think we've even, you know, we at the beginning of the year, we had that fantastic recording where you made the Star Wars analogy of, you know, a new hope.

And and, you know, we were kind of joking about, you know, we're in different phases if we equate this to Star Wars and, you know, what's going to happen to C++. It's going to be interesting to see. And the point being is that, like, having these two different podcasts that I listen to, one which is, like, the premier C++ podcast where they're talking about reflection and how progress has stalled, and then they're just like, yeah, that's unfortunate. I think that really we're starting to see, severe cracks in, in the C plus plus, you know, what do you want to call it? Language or evolution process is going to lead to quote unquote C plus plus

dying. And I think that death has already started. And also too, I know that there are going to be, I don't think that these are new problems. It's, it's simply that we've, we're talking about the problems now it's it's it's been this

way for the past two decades yeah but but i i know that there's going to be listeners too that are thinking c++ is doing just fine i think that was number seven on my list was it is it is it is doing just fine like right now like yeah so team or doomler he gave a a keynote at c++ on c where he said that basically we don't need to be worried about safety. It's being overblown. Go watch the talk if I'm misparaphrasing. But and then one of his points is that like C++ is going to be just fine.

And I think that like if you don't like the word dying, replace the word dying with sun setting and be okay with the fact that basically the direction that C++ is headed is that direction of COBOL. If you are, you know, a C++ expert and you want to do C++ work for the rest of your career, even if you're, you know, just out of university, you can definitely do that. There is going to be C++ repositories that are, you know, big companies are working on, you 50 years from now there's no way that that but the thing is like like this this is not an inevitable future and that's one of the reasons why i made that star wars analogy is that like c++ is not doomed i do think it may be dying

but it's not doomed like we we could we could solve our problems if if if we had the will to do so. We could modernize our process. We could change the level of risk that we concern ourselves with. We could improve our stakeholder structure. We could find ways to move faster. So here's my question. Look, simple solution.

Deprecate all existing C++ implementations. Circle is now the reference implementation for C++ and appoint Sean Baxter the dictator for life. That's not going to happen though.

That is not a realistic... But I'll tell you what, it would solve a lot of our problems. So here's the thing. You're saying technically as a former statistician actuary, that is a possible future.

Not a probable future, but it is a possible future. That is not out of but it is a possible future that is not out of the realm of possibilities. That being said, it's not realistic, and that's why I think C++ is doomed. No, but that's the extreme version. I think that there's non-extreme versions.

I don't even think the non-extreme versions are going to happen, though. And here's the thing. Here's my question. I'll tell you what the problem is. Let me ask my question. If one of these non-extreme versions or the extreme versions happened, do you think that the people that have been turned away from the evolution process that are not involved would actually come back to the language? We don't need them.

You don't need them. The problem that C++ has, and Bjorn actually wrote this in his Vasa paper. He wrote about how C++ is 300 individual authors, each with their own goals and objectives, that we're not a team. We don't have a shared vision. Everybody comes to the committee with their own objectives and that's why something like reflection is failing. Why is reflection failing? Reflection is failing because there were three people working on it and two of those people are now working on something else and the other person doesn't really have the bandwidth to be able to fully commit to it. And that's because it was all their project

because on the C++ committee, everything is driven by individual authors. It's for many of the same reasons that I think that the Boost libraries have had trouble evolving and modernizing over time because the Boost libraries was a collection of 150 different libraries, each with an individual author.

And with the exception of Dave Abraham's, there was never really somebody in the Boost world who could make unilateral decisions, unilateral global decisions, like for example, to move Boost to a new build system, or to do any of the other things that might have helped Boost to be more successful than it currently is in the modern era.

And C++ has that same problem where it's a collection of 300 individual authors and champions. You know what? We don't need a committee of 300 people. The fact that we have 300 people on the committee is a problem. I don't need people to come back to the committee. Did we lose some really good people? Yeah. But we also have some good people. The problem is we have too many damn people. If you want C++ to be more successful, the real reason why it's going to be so hard to improve the C++ process is that to improve the C++ process,

you need to get the 300 people who are currently on the committee, you need to get some large percentage of them to agree to disenfranchise themselves. You have to get a large chunk of those people to give up their power and their veto or their voice on the committee in favor of a lighter weight process to get some of the chefs out of the kitchen so that we can have a nimbler process. And like, that's really, I think the only way that we can realistically save C++ is that we need a different stakeholder model. We need a different evolution model

where we can make decisions in smaller rooms and where we can make decisions that are more implementation focused. And also where we can make greater investment in implementations, because one of the big problems that we have today is that implementations are just drastically understaffed. And you see this, like this is one of the reasons why it takes so long after we standardize a feature for it to get adopted. Like, you know, we talked about this earlier with modules. Like, why isn't, why don't we have modules everywhere? Well, it's because we don't have enough people contributing to all the compilers. And like I said, that is somebody who works at a company who is, who, or I have spent a

good chunk of my time at NVIDIA advocating for and us to increase the size of the team that we have working on our language front-ends. You know, it's always hard to get investments for things like compilers and programming languages and for core library teams, because it often has non-tangible benefits that are hard to directly associate to revenue. So yeah, we don't need people to come back. We need some of the existing people who are involved in the evolution of C++ to give up power to a smaller body that can make decisions in a more nimble way. All right. So let's wind down, wrap up episode 150 of ADSP the podcast with the following summary slash question.

We already both answered. Is C++ dying? That's a yes from Bryce, a yes from me. Is C++ doomed? That's a no from Bryce and a yes for me, which means my answer to the final question, is there a realistic chance that the change that needs to occur for C++ to shift direction from dying to thriving? Yes, I think it's possible. I would even go so far as to say that I think it is likely. But I think that things will probably get worse before they get better.

But I think that there is, you know, a next generation. At some point, there will be a passing of a torch from the current generation of leadership to a new generation of leadership. And I think that represents great opportunity and potential for reform and in change. I mean, I think it's going to be hard to get everybody on board. I'm glad that that is not my job, it's somebody else's job. I don't have the time for that sort of stress, but I think that there are others who believe as I do that the writing is on the wall and that if we don't change things, if we don't improve our process that the language will eventually die. And I think that is a great motivator.

And I don't think it's as hard as people make it out to be to make things better, to reform, to modernize. And also, I don't think that C++ is some special language where we have to do things a certain special way because we're C++. We are 20 to 30 years behind the curve in how we collaborate and work on the C++ programming language. And there are other languages that are as big or bigger than us that have found ways to modernize, we can do it too. So final comment. I know the person that you, I think I know the person or one of the people that you are saying believes that there is a existential threat and change needs to be made. But I can only think of one.

I'm not sure if there's multiple people. I would be surprised if you know who it is because it's not your favorite person. Oh, so we're going to bleep, but it's... Correct? Yeah, yeah. Yeah. And you should bleep it and leave that in there.

But wait, wait, wait. I'm going to give you a better clue. I think they are the person best equipped to save C++. Yes, so I did correctly guess this person, and I agree that they are. Wow, I'm shocked to hear you say that. Hey, I have my personal feelings. And I don't think that it needs to necessarily

be that one particular person. I just, I think that... Well, so that was my question. Are there, because I am not confident, like that's the only person I can think that there would be hope, and I don't think that person is going to get the reins. So – You know, I don't know.

They might. They might get the reins. They might. But if all of C++ hinges on this one individual getting promoted? I think that it's far less important which particular person is running the committee. I think it's more about the generational change, that there is a passing of the torch that is undergoing. And I think after more of the passing of the torch has happened, this will sort of have the next generation of leadership. And even if a particular person is in charge versus is just is in some other role, I think that inevitably we will move towards reform.

I think there is a question of the speed at which the reform comes and does it come fast enough to truly save the language? And by the time we make the improvements that we need to is it is the writing already on the wall but i think that c++ is the sort of technology that has come back from a winter before so i i think that um i i think that that there's you know the the the 2000 to 2010 was a real rough time for c++ um but then we had a renaissance and you know maybe maybe we'll have an enlightenment this time um you know i i think that uh that it could be another dark days cycle for c++ certain Certain people in charge could certainly accelerate things. Yeah.

I think that a part of the problem though that you're potentially missing is that this passing of the torch to the next quote-unquote, you know, generation. I know some of the folks in that next generation and they have the same they're of the old guard. They're in the, they're, they're of the old guard.

They're in the new generation, but they're of the old guard. And I just, I think depending on who, you know, I don't think it's a, a, a sure thing that once this torch gets passed, that we are now focused on a new direction and how to pivot. I think that there's a possibility that you pass the torch and nothing changes. I do think that the passing of the torch, one thing that the next generation of leadership almost universally has in common is the outlook on diversity and inclusion, which is a major non-technical challenge that the community faces.

Really? We're going to bleep out another name. What about you think he's in that boat? Yes, I think so. We're going to cut all this obviously because it can't go in. All right. You probably just heard some chipmunk voices or I don't know. Maybe I got to cut it all out just in case because if someone could slow it down and get what we were actually saying, that's a – what do you call that?

Inside baseball something, something. Maybe we'll start a premium podcast, which I never, I never want to do. Cause I never want to put my content behind money paywall, but we could just do like, if you, if you want, if you want to pay me a hundred dollars a month, I will give you all the inside gossip. You know what? We'll, we'll start an only, we'll start an only fans. Oh Oh, yeah. An OnlyFans where we just talk about inside baseball. Anyways, folks, let us know what you think. Is C++ dying slash sunsetting into the land? I wish you hadn't said that because there are definitely going to be a lot of people who are going to let us know what they think.

And I'm definitely going to get a lot of blowback from this episode. It's fine. Honestly. definitely going to get a lot of blowback from this episode it's fine honestly so if you if you have if you if you liked things that i said my name is bryce the whole bag and if you all right that's a wrap for episode 150 we might be doing a couple special things we are i know we can't confirm the one idea, but I think we definitely are going to figure out how to do either a

Twitter spaces or some kind of Discord or YouTube live stream where we record an episode and give folks the ability to interact and do an AMA. We might not have you have the ability to talk into a mic and ask us live, but we will have some kind of, you know, question and answer participation.

I think we're I think we'll try and do it on Twitter, Twitter spaces and having a modicum of success in interacting with folks that want to listen and interact. And we've got a couple other things lined up. We're coming up on the three year anniversary. We got to figure out to do something special. And yeah, we'll say have a good day. Yeah. Be sure to check these show notes either in your podcast app or at ADpthepodcast.com for links to anything we mentioned in today's episode as well as a link to a github discussion where you can leave comments thoughts and questions thanks for listening we hope you enjoyed and have a great day low quality high quantity that is the tagline of our podcast it's not the tagline

our tagline is chaos with sprinkles of information