Algorithms + Data Structures = Programs - Episode 98: The Future of C++ with Sean Baxter (Part 2)

Episode Date: October 7, 2022

In this episode, Bryce and Conor continue their interview with Sean Baxter about all of the C++ successor languages.Link to Episode 98 on WebsiteTwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Sean Baxter is an independent programmer and the author of Circle, the next-gen C++ compiler. He formerly worked at DE Shaw Research, NVIDIA and JPL.Show NotesDate Recorded: 2022-09-25Date Released: 2022-10-07Sean Baxter on TwitterSean Baxter cpp.chat EpisodeSean Baxter CppCast EpisodeCircle CompilerVal Programming LanguageJakt Programming LanguageCircle Metaprogramming: Better Features Make Better Libraries - Sean Baxter - CppNow 2022Carbon Language: An experimental successor to C++ - Chandler Carruth - CppNorth 2022Carbon Programming LanguageCppFrontCppCon Keynote about CppFront: Can C++ be 10x Simpler & Safer? - Herb Sutter - CppCon 2022CppFront Reddit ThreadSwift Programming LangaugeRust Programming LanguageArthur WhitneyPython Language Summit 2022The C++0x “Concepts” EffortSwift ProtocolsRust TraitsCarbon InterfacesC++20 ConceptsIntro 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

I would like to encourage us as a community of 7 million C++ developers around the world, as we consider C++'s future, to push the boundaries to bring C++ itself forward and double down on C++, not be quick to switch to something else. Welcome to ADSP the podcast episode 98 recorded on September 25, 2022. My name is Connor and today with my co host Bryce, we continue our conversation with Sean Baxter about the future of C++ and all of the C++ successor projects. What do you think of that? And like, also, like if you had a crystal ball or you had to bet, you know, five, 10 years from now, what do you, what do you think the low-level language space is going to, is everyone going to be writing in circle? Is it going to be

C++ is just going to be in slow decline or i mean i my whole adult life has been c++ and i don't want to learn a new language just because other people say i should learn it or because other people say it's better i am i feel confident in c++ it can express my intent and we can make it better. And also, there's another million people who have been using this language successfully with some frustration, sure, but they've built the whole modern world out of C++. And I think we're going to keep with this language. We should make it better. And we should kind of honor this, you know, multi-billion dollar software investment that's been built up over decades. And I think the future will

look, hopefully, like today looks, just with a better language. I mean, I just don't see everyone jumping to Rust and then putting these huge, complicated source bases in jeopardy. They say Rust is safer, but not when you have to rewrite everything you already have. I agree with Sean, and I think our biggest problem is our evolution process. And I think that if we can improve our evolution process and if we can, if we can develop the willpower to make C++ a better language, I'm, I'm confident that we can do so. I do not believe that there are fundamental technical challenges that,

that cannot be overcome here. I think we could move two, three, four or five times faster. If, if we had a better evolution model and, you know, not everybody's going to necessarily be happy about, um, what moving faster would look like. Um, and it would mean, I think everybody would have to make some compromises. But I think that it's doable.

I do think that if anything dooms the language, it would be that. But I don't think C++ is going anywhere. I just don't want to see it go the route of a COBOL or a FORTRAN because it's not kept up with the times. Yeah. I think any language you can imagine, I think we can really get there from C++. And I think maybe that's the shortest line even because it's so hard to generate new user base. Apple could do it with Swift because you had to buy into their whole Objective-C slash Swift framework.

They have a kind of a walled garden. But for everyone else, if you start with C++ user base, man, what an amazing amount of momentum you have going forward. And it's not just the user base. It's the ecosystem too. It's like inertia is king in software. Like if you have

something that has inertia... I think momentum, you should say momentum. I mean, inertia's kind of got negative connotations, but... Okay, alright. Momentum is key in software. And everything that I've seen in my career

tells me that everything i've seen in my career tells me that it's better to try and incrementally improve what you have in front of you instead of rewriting it all from scratch i i get that the rewriting it all from scratch has worked for Arthur Whitney. And I certainly, I get that there's times when that is the right thing to do, but the cost for that is so high, especially when you've got an ecosystem and a developer base out there,

when it's something that's a community project and that, uh it you know rebuilding that community um or moving that community um especially when the size of c++ is just so much effort and so much work whereas just in like like investing in c++ and making it better, I think the returns are going to be much higher. But I have started to reach the point where the timescales on which, like we do good work on involving C++. I still believe that. I still believe that the committee does good work.

The timescales on which it happens trouble me. And it's not any one individual person's fault. It's not that people are dragging their feet. It's just the architecture of the system. I think the way

to deal with this is to get vendors that are active. And like I said before about these idea of extension sets, like a pound pragma feature tuple, right? So I have that, and that has one break, which is comma-separated expressions in parentheses now are tuples as opposed to invoking the comma operator, right? So that's a break, but you have to opt into it by using this. So I could develop this thing out and that could become a proposal. And then it's just something you vote up or down on.

And then if it's approved, that becomes part of the next version, right? There's ways we can put out very coarse grained proposals. Because right now there's too many proposals, a lot of them for tiny, and you just clog the system up. And if we had something that was big and it was like a vendor supports it and it had users, it's just easier to say, yeah, we should take this thing because it's thought out and it's deployed and we can bang on it. Well, one of the fundamental problems of the C++ committee

is that it's not 350 people working on a single project. It's 350 people, each with their own independent vision and goals, each working on their own independent proposals, usually without a ton of consideration for what others are doing. There's a lack of goal setting at a high level on the committee. There's a lack of priorities. at a high level on the committee. There's a lack of priorities. And it's not a team. It's like even if we do set our goals and agree that we're going to do X, Y, or Z, or say that we agree that we're going to do X, Y, and Z, not everybody gets behind that. And without that team commitment, yeah, it's impossible for us to work together as a committee. We need to have a clear vision and direction, and it needs to be something that everybody buys into.

And to your point about active vendors, I'll say this. This will sound controversial, but I fundamentally believe I'm right about this. I think it would be a much better model where the, just the vendors got together and decided upon new features. Um, all of the vendors of compilers, you know, who their customers are, their users. Um, and this, this current setup where we have tons and tons of users and other stakeholders involved, it so dilutes the vendors' voices. And honestly, like it makes a lot of the vendors very, very, very conservative

in what they try to do in the committee. And oftentimes it forces the vendors' hands. I think that the people who implement c++ compilers um probably have a better perspective on what users as a whole need than taking a random handful of c++ users and saying hey why don't you tell the come dictate to the compiler vendors what they should do i'm'm certainly saying, like, certainly user input is important, but, like, I just think we've gotten to this place where there are some on the committee and in the community who think that people who develop C++ compilers

somehow don't talk to users, or, like, users are their enemies. Like, that's absolutely not the case. If you're developing a C++ compiler, like, your goal is to that's absolutely not the case if you're developing a c++ compiler like your goal was to like serve the needs of your users so yeah i i in my ideal world you know if you look at how some of the web standards um run and some other you know more modern standards i would i would take you, representatives from all the major vendors and I would get them together to collaborate on new features. And I would maybe have a few people who are not from, you know, who are not compiler implementers. But it would have to be people whose full time job is evolving the language.

Yeah, I'd rather have a cartel model. Yeah, yeah, yeah i mean doesn't um uh python has something called i think the python language summit i maybe got the name of that wrong but basically there are you know everyone can submit peps or whatever they're called but they they also have a once a year language summit where only the developers that work on the Python language are there. And like, I think there's a couple people that might get special invites, but it's not, it's not like a open thing. Like there's PyCon, everyone can go to that. But then the language summit is just for the language implementers. Yep. I would like that model. Here's a question, Sean. So you mentioned that one of the things that is necessary for, you know, to just summarize, you know, carbon is a vision.

CPP front is a vision, all these different visions. And in your opinion, any vision is possible and it's possible within the C++ that we currently have and we can get to it if we want to. And you said active vendors is something that would be necessary or would help with that. Are there other things like it kind of, you know, I think we had an episode a few episodes ago that was titled like C++ should leave ISO. Like, do you think these visions are possible within an ISO framework or does there have to be like a drastic governance model change in order to get there i mean i we know bryce's opinion now which is actually i'm not sure what your opinion is on

that but i well my opinion is is pretty simple um it is likely infeasible for c++ like to just, for like the C++ standard IP to just like get up and leave ISO. Like that's... I think that's another... It's a little bit more interesting. ISO has no motivation to do that.

It'd be very complicated to do that. But there are other ways to develop standards that get published as iso standards um i'm not saying that c++ can't continue to be published as an iso standard i'm just saying it should not be developed uh uh at like on by an is ISO working group. I think it would be much better for C++ to form its own standards development organization to develop future revisions of C++

and to publish those future revisions of C++ through ISO's fast-track processes that would allow it to be an open standard. And it would also allow C++ to pick an evolution model and a stakeholder model that makes sense for C++. That, to me, seems like the only practical way to dig ourselves out of this hole. Now, if we were starting from scratch, if we could just leave ISO completely, sure, I would say that that makes sense because in this day and age, ISO is not the right fit for C++. So that's pretty, that's kind of nuanced. I'm still not quite exactly sure where you stand,

but my case is I don't really care that much, I guess. I mean, I'm just like trying to find my way through and try to arrive at a set of language features that is expressive and kind of continues to support existing code and provides a path for more productive development. And I don't know if the ISO really matters that much to me. You know, you're going to come out with standards every three years. I'm going to do my best to implement it and keep up with the other compilers.

But, you know, from my own standpoint, like, if there was a company that got sufficiently scared about successor languages that would be incompatible with their own source bases. Like, Herb seems kind of agitated, at least. You know, if they want to support this, I mean, they could handle the standardization approach however they want, whatever's good for their business. Just like Google is doing. I mean, Google has got a different development model

that works for them, or they hope will work for them. Yeah, it's interesting the way that you phrase that, because it helped me understand a bit about how you're operating. Just what you said, that you don't really care that much about what ISO is doing. And that sort of gets to the debate that we had earlier, that your point is sort of that, I think something like me or maybe most C++ users or some set of C++ users, this is a high value on things being standardized.

Not most users, a tiny percent. Yeah, maybe it's a tiny percent. Maybe it's a tiny percent that values things being standardized. And your point is like, look, I'm just going to build the best features that I can in my compiler and other other compilers can build them if they want like i want to focus on the language not necessarily what's standard i i wasn't up to date at all with standardization prior to starting circle like i had all these ideas i didn't know that 17 was a release year i didn't know that 14 was a release year i don't't even know that 14 was a release year, I don't think. I was on 11, and then, you know, you just do your work.

I would rarely go to the standard to look stuff up because I wasn't, like, writing that kind of code. I'd go to CPP Reference and get, you know, clarification on that. And I certainly wasn't reading the monthly mailings. And I don't think a... But they weren't monthly until seven well okay whatever that's that's my point that's my point you know like that is nobody cares about that i know and um yeah i mean i don't i don't have any hard feelings

about the committee really like keep doing what you're doing. That's fine. If, if I, if, if vendors like myself or bigger ones would, you know, periodically present you a, like a mega proposal where it's a simple up or down vote. This is how you can get interface generics, like C++, OX concepts. And we thought,

we thought it through, we've deployed it. You can just take this thing as is because that would make it easier to merge into the standard. Hopefully if they want to provide that, that's like a good service. And then for customers that really just want to remain with ISO C++, they would benefit from that because they would get accelerated features as well. I just want to write a better compiler, a better language.

And I think the committee has to figure out how to stay relevant. See, I think most on the committee, your perspective is I can do valuable work on developing new C++ features without having to propose them for standardization. Like for a lot of people on the committee, whether or not their work is valuable depends entirely upon whether it gets into the standard. They should be writing software. Right. debacle if instead of the losing side walking away from the committee it's perhaps unfair

what if both sides had just like developed their version of concepts in their compilers and just not really worried that much about what the committee their version of concepts in their compilers and just not really worried that much about what the committee was doing. Like, okay, the committee didn't standardize my version of concepts. I'll just keep developing it.

I think we might be in a better world today. Yeah, I think there would have likely been a compromise at some point where they said, okay, let's... And to be fair, that did happen for some period of time. But I think eventually what happened was the folks that were working on the OX concepts and on the implementation of it,

which was more mature than the concepts light, they became disheartened. And for them, it didn't seem like it was a valuable investment of their time at some point because the committee seemed to be moving in the direction of this other proposal. And I think that is the downside, I guess, that if the committee does decide to do something, it's just drastically different than what you're doing. Yeah. But I do understand now, I think, a little bit better what you were uh the point

you were making you don't you don't need anyone's permission to write software just because something's right it hasn't been put into an international standard document you know you don't need to wait for that to write software and people aren't waiting yeah like the game industry has developed their own set of tools for reflection and things and they're like really kludgy yep but you know they need it and so they go and things. And they're like really kludgy. Yep. But you know, they need it. And so they go forward and do it. They're not just waiting for the day.

And I mean, I like, even as one of the senior committee leadership, I constantly question whether the work that we are doing is valuable. And I think anybody who is deeply involved in C++ standardization, you know, you stick your head up from being down in the weeds and you have to ask yourself, was this really, was this the best use of my time? Was this like, was spending, you know, six months trying to hammer out like the details of this one specific thing

in this feature. Was that truly, truly like a valuable contribution? Um, yeah. And, and I mean, I think it's, I think it's good for us to, to question that. I certainly hope that lots of other people in the committee ask themselves that question. I certainly do. Yeah, I'm not even going there. This is all you. Yeah. So here's a, I mean, this is kind of a specific question, but I kind of assumed in my head when you were talking about the C++ OX concepts that you were in the process of adding that that was going to be not possible to coexist with C++20 concepts.

But it sounds like you're still fully supporting both. Yeah, so C++20 concepts are not concepts. What does C++20 give you? It gives you a concept definition or declaration, which is like a variable template. It's got a bool value. You give it some number of template parameters or arguments and it's true or false. It gives you a requires clause which

you can put on the end of a template or a member and it evaluates that and if it's false then it removes it from the overload candidate set. It also gives you like it requires expression which is the same thing but inside an expression. These are like mechanisms that use the same keywords as C++, LX concepts,

but they, they just work as like normal language features. They don't lock you into this alternative system of early type checking. And, and the C++, OX concepts that I'm implementing or that Carbon is going to implement and they call those interfaces and impuls and Rust calls traits and impuls and Swift calls protocols, those are basically orthogonal to what we got in 20. The early type checking does not exist in 20. It's a lot harder.

It requires, I think, creating new kinds of data types like generic classes. Yeah, they all coexist, and I think it's clear, at least in my implementation, it's clear the distinction between the C++20 concept and the interface that I'm having. There's a different set of keywords. They go in different places in the template declarations. I'm definitely committed to providing both of those. And also, it's sort of incremental.

You don't actually have to fully opt into these interfaces because the interfaces I've written, it's like a... So the interface in Carbon or in the trait in Rust, it looks like a class specifier. So you have an interface name, and then it's got some list of associated types,

which look like typedefs, or function declarations for the associated functions. And that defines your interface. And in my implementation, that interface is also a concept. So you can pass that around as a concept. So you can pass that around as a concept parameter. You can use that in a requires clause. You can use that to constrain a placeholder parameter. You can use it wherever you use a concept. And it's just like a better C++20 concept. It does type checking over the whole type as opposed to just evaluating this Boolean expression. So in that sense, it gives you like a half measure way in.

And then if you want to go all the way in, you can make a generic function with the generic keyword, and that'll do the early type checking. And that's going to require like some real thought on the part of the users, because you have to be able to marshal all of the capabilities of the types and put those in the declaration.

It's pretty challenging for me because I've never really dealt with this kind of generics before, but other languages are using it apparently with success and people are not complaining so much about the error messages in these other languages. So hopefully we can get errors to be more clear and the documentation would be

kind of like enforced almost as part of the definition of the function. Yeah. Yeah. Interesting. So this really is just like you're saying, you know, you said this earlier, it's just stop being scared. We can have it all.

Everything can live in C++. Because I was thinking we can't have two different types of concepts. Concepts are concepts. Which also should be the title of this appointment. Well, I mean, I'm using new keywords to prevent confusion, right? Yeah. Just like Carmen is using different keywords. But I liked how you said that.

The concepts that we have in C++20 aren't really concepts. Well, they're not. I mean, they're not the generics. That's why people are still agitated. They're still angry about it. But I think we can add everything. I think that was one of the objections to my CPP Now talk from people was that I've added a bunch of new mechanisms. You're making the language too big.

They say you're making the language too big. And what I said was that this is reducing the time to solution. It drives me crazy when people bring up this complexity argument because i i think it's something that people bring up when they like don't like something but they don't have any technical reason for why they don't like it right think about a um a jet cockpit like 50 years ago it was all pressure gauges hundreds of pressure gauges and that was that was a simple design and now you have like a couple of like LCD touch panels. And, and that's hundreds of times more complicated.

Right. But it gives you the information you want right there. The, the time to solution is very quick. You can display whatever you want. It's got a whole, a whole lot more capability yet in every way. It's,

it's better. I mean, it's definitely more complex. Digital systems are just more complex than analog ones. But they're better at the same time. And nobody's expecting you to learn all of those things. Nobody expects you to know how every feature in

any modern device works anymore. But if you need to find it, you can find it. And for most of your tasks, it's just much easier to use. Well, and there's always this specter of teachability. You know, oh, well, if we have all these things that we have to teach the old thing and the new thing. You know, I and people often joke about that.

Everybody who's, you know, all the big C++ figures who talk about making the language simpler, that they're really trying to make it simpler through more complexity. And people act like that's a, that's like a ha-ha thing. But I think that in a lot of cases, you do make the presentation of something simpler by making it more complex.

And like, you do get to a simpler language by adding more features. And I think we've talked about this in the past, that at any point in time, if you ask the C++ community how the evolution of C++ is going, 50% of people are going to tell you it's moving too fast, and 50% are going to tell you it's not moving fast enough. Yeah, it's this fear of adding new

things or the fear of adding new things solely for the fear of adding them. Right. I think that's the one objection I don't have any sympathy for. Yeah. I think that's the one objection I don't have any sympathy for. I think there's a lot of other things. Okay, I understand your opinion.

But on this one, I just do not. To be fair, the one place where I hesitate on this is on questions of what goes into the standard library. On questions of scope like I'm not saying like we should add everything. Like it has to still be

like a valuable thing. I'm just saying that like there's no reason that we shouldn't add, you know, interfaces when we already have concepts because clearly that's a thing that's valuable and that would you know, benefit a great deal

of users. Well, not even saying add. I'm just saying there needs to be an active project to discover how they would actually behave in the C++ environment. Yeah. But I don't want to suggest that I'm saying that we should add everything that anybody might want to add to C++, in particular the Stated Library. Please don't send more proposals. Yeah, we're just

saying that the weight of the compiler, like the number of lines of the compiler, the number of countable discrete features isn't a good guidance of the user experience, how complex the language is. Because you add first-class language features and the user experience improves.

Absolutely. Absolutely. I think that JetCockpit example is a really good one. That's a really nice way of putting it. If you think about it over the past 20 to 30 years, computers have become far more accessible. It's like everybody's grandparents and kids is able to use a computer because they all have these much simpler interfaces and much more user-friendly operating systems. And yet vastly more complex than everything. Yeah, exactly. It's like wildly more complex.

And I think we can square those things. We can do that at the language design level too. I'm putting in choice types. I'm putting these things in. And it's like it's not harder for the user. It's only harder for me. Yes. All right.

So I think we got to talk about the last thing that we promised the users we would talk about. Connor, have you read Moby Dick? Oh, yeah. Tune in next week for part three, the final part of this three-part conversation with Sean Baxter. Thanks for listening.

We hope you enjoyed and have a great day.