Algorithms + Data Structures = Programs - Episode 97: C++ vs Carbon vs Circle vs CppFront with Sean Baxter

Episode Date: September 30, 2022

In this episode, Bryce and Conor talk to Sean Baxter about all of the C++ successor languages.Link to Episode 97 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-09-30Sean Baxter on TwitterSean Baxter cpp.chat EpisodeSean Baxter CppCast EpisodeCircle Programming LanguageVal 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 LanguageClang: a C language family frontend for LLVMCppFrontCppCon Keynote about CppFront: Can C++ be 10x Simpler & Safer? - Herb Sutter - CppCon 2022CppFront Reddit ThreadSwift Programming LangaugeRust Programming LanguageGoogle C++ Style GuideRust choice TypeRust TraitsCarbon InterfacesSwift ProtocolsThe C++0x “Concepts” EffortIntro 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 97 recorded on September 25th, 2022. My name is Connor. And today with my co-host Bryce, we talked to Sean Baxter about C++, Carbon, Circle, and CPP Front. We've got bidirectional is the infinity sign. Omnidirectional is the circle. Dario is the overlapping Venn diagram. And cardioid is the...

Okay, which one do I want to be on? Probably omni or yeah, omnidirectional. Okay, I'm sorry. Connor, Connor. There are Probably Omni or, yeah, Omni Direct. Okay, I'm sorry. Connor, Connor. There are four symbols. Oh, yeah, right, right. The circle, the circle, the circle. It's topical that this is a perfect segue into having Sean Baxter.

Better not be Cones and Robs. All right, so we should introduce our guest yeah Bryce you can take this introduction hang on my dog is staring dead into my eyes right now

I am here in my lovely Manhattan apartment with Sean Baxter the creator of the Circle Compiler, which I personally think is the future of C++. Sean, maybe you should introduce yourself. Thanks for the introduction, Bryce. Hi, Connor.

I'm here to, I guess for a really aggressive interview, it sounds like. Yeah, that's correct. An adversarial one. I'll try to, it sounds like. Yeah. Embracerial one. I'll try to stay in my toes. Yeah. Did you listen to the last episode? Because what happened when, I'm not even sure I'm allowed to mention it, but I was asking Bryce if we were going to talk about some topical news

that had come out in the last previous week and then about a sort of successor to C++ kind of area. And then he was like, oh, do you mean jacked? Or no, first he said, oh, do you mean Val? And then I said, no, you know I don't mean Val. And then he said, oh, you mean jacked? And then out of that, he said, oh, we should bring on Sean Baxter, because Sean has looked at all of the languages

that are supposedly going to replace C++ and has opinions to share, including obviously... I think more importantly, before everybody decided they wanted to make a successful language in C++, like predating it by like three or four years, Sean decided he wanted to make C++ better. Yeah, and for the... I make C++ better. Yeah. And for the, I mean, we should, yeah,

do like, you should introduce yourself a bit for any of the people that haven't listened. You have, I think, two different interviews, one on CppCast and one on CppChat. And I distinctly recall being in Sunnyvale and I think I was either on a bike ride or on a run when I was listening to that CPP chat episode. And I like, I was like floored because they were just, you were just talking

about how you had written a C++ compiler, like single-handedly by yourself. And I was like, wait, what? And you were, and then I think it was like, I can't remember. Yeah, it was probably the CPP chat one. And the hosts were just like, well, let me get this straight. Over three years, or I think it was two or three years, you just single handedly by yourself. Like, meanwhile, the other people implementing compilers are teams, scores of people, and you just did it single-handedly so anyways you can right so it's been six years now that i quit my job i have this epiphany about compilers and i thought like the initial idea was to rotate the language from the compile time into the runtime domain or rather let me say it again to rotate the language from the runtime to the compile time domain so what used to be code that you could build and execute at runtime, you could evaluate it through the interpreter at compile time. And that way, all the standard library and pretty much all code

would be available to you to use for compile time programming. And that was the impetus. So I have a meta token that you can put in front of a statement, and it'll evaluate that and create that object at compile time. It doesn't care about constexpr or anything like that. You can have mutable state, and it kind of blurs the line between a compiled language and an interpretive language.

It's still statically typed. It still generates object code at the end. But now you have access to a greater you know, a greater vocabulary of functions and types to do your work. So you can open a file at compile time, read in data, and then kind of reflect on that data to emit code programmatically. And that was, you know, that was the original idea. And it was actually a really great way to start writing a compiler because I didn't have to worry about LLM at the beginning. I could just use the interpreter and evaluate my own source code at compile time. So that was an easier way to bring it up. So instead of having to worry about a front end and back end building both of these

simultaneously, it was like, I'll just build the front end. I'll try to consume all of the, you know, STL headers. I'll try to consume other open source projects to get this thing built. Instead of worrying about emitting object code, I could just run it inside the compiler. That was a good way to bring it up. That's

pretty amazing. I want to go back to the first part of that amazing story, which is you quit your job. You believe in this so much. Just take me through that. You had such conviction in this, that this needed to be built. Right.

I didn't really know what was in store for me. And I'm not sure I would do it again. But on the other hand, I think it's kind didn't really know what was in store for me and I'm not sure, I'm not sure I would do it again, but on the other hand, I think it's kind of in my nature to do this. Yeah. Um, it's been, I mean, it's been like really difficult. Um, and I haven't had any money. I haven't had any income since then. So one motivating factor behind this is just like, I don't want to end up penniless and

with nothing to show. So I put a lot of pressure on myself to produce. So I don't get bogged down in problems. If I see a can of worms, I do not go open it. I try to stay productive and I just try to write code. And I have this sense of just being able to cruise through any issue. And I think I've always had that kind of conviction. It's just a matter of willpower.

So if you have the idea and there's an idea that's attractive and if you can sum it up with willpower, then you should go and do it. I didn't have any other, you know, dependence or anything like that, so I might as well follow my dreams. That makes things a little bit easier. Yeah, but I think since then Circle has evolved a lot and it's gone a lot of different directions. So I've had two distinct pattern matching implementations.

I've had a shader. I embedded the GLSL OpenGL shader language into C++, and I can emit the Spear v intermediate representation, which is used for Vulkan and OpenGL code. So you can program any of the 12 shader stages in C++, just like you would CUDA. I have a CUDA target, and at CPP Now, I gave a keynote on pack metafunctions and enhanced parameter packs at JOR. It was a great talk. I loved the talk.

I was sad when people had so much constructive criticism afterwards, but I thought it was a great talk. Yeah. I mean, I'm just trying to explore different language ideas. And some of these are really radical. I don't think any of – like, these things I'm talking about aren't things that will appear in proposals. And there's certainly one thing that – they're not things that are likely to be standardized. But are they radical? Or are they radical for C++? And I ask that like if C++ was a younger language or if C++ was evolved like some other languages are, would some of these proposals be seen as radical as they are in C++?

I don't know. It's hard to say. I mean, we are where we are yeah um yeah so uh do you want to like pivot to the uh successor language question because i think that i have a few i have a few other uh this is gonna be awesome because i'm just gonna sit back and let bryce this and so i'm just gonna get like an advanced preview screening of this interview here. Okay. So next discussion. So Circle is not open source.

Right. And I think a lot of people maybe find that surprising in this day and age. Can you maybe explain why it's not open source? Yeah, I don't want to have to respond to people. I need to be able to sit back and think about things. So for the last, like, three months, you know, two or three months, I've been thinking about generics. And I have to be able to tune everything out. And the idea about if you open source it and you have, like, pull requests and you have all these demands on your time.

This is still a research language, even though it's a full compiler. It's 275,000 lines. I've run a lot of test weeks through it. For me, it's still about exploring ideas. For me, I want to spend my time developing ideas and I think responding to users. There's so many odd demands that I can't satisfy. So I'm just trying to do the best I can. And at the same time, I feel like I don't owe anybody anything right now.

It's not open source. I'm not taking anyone's contributions. This is giving me more freedom to build a tool and take it any which way I want. Right. Because making something open source is sort of the act of giving away some degree of control over what happens to it because then you have contributors that come in. It's the commitment to support kind of a community even. Yeah.

Even if you just have like a few contributors, it's still a demand on your time. And, you know, I like having kind of high level conversations with people if they have features they're interested in, like, I'm, you know, happy to try to implement things and see how they how they feel. So I like kind of interacting at that level. But yeah, I it's, I think it would really slow the process down if I had to kind of give people a stability guarantee as well as pulling in their contributions. The ability to like just change the- Sorry, the dog was tearing at something she was not supposed to be tearing at. Moony, come here.

Continue talking. Welcome to ADS Be The Podcast. It's really gone downhill since the beginning. continue talking oh welcome to ads be the podcast it's really gone downhill since the beginning you know bryce likes to have his dinner while we record you know the dog is like a basically a third co-host at this point okay we got okay the dog is on bryce's lap now like yeah a small child. Because the dog was trying to eat her dog bed, which I've had to sew up holes in that dog

bed three or four times. She really likes pulling stuffy stuff. The last statement about open source is that since I don't have any source code users, I'm free to refactor the code continuously, which I do. And you can't really have an open source project

where the internals of it change so rapidly. It just breaks everyone's downstream projects. So for me, at this point, it's important for me to stay nimble and to myself. But it is for Liabeau, right? If you want to use the binary. Sure. And it's interesting. Connor and I last week talked about

another... The K programming. Yeah, the K programming language, which is another language that is developed by a single visionary person. It's not open source and it's just released in a binary form.

And I think there's sort of many similarities to that evolution story. Although, interestingly, with the K language, there's different versions of the K, or different evo... Not versions, but evolutions of the K language. And when the guy, Arthur Whitney, decides that it's time for a new one, he deletes all the source code for the old version and starts over and deletes all the binaries. And it's just – it's completely from scratch. Well, that's a 30-year-old project. I don't think I want to go for that long. Yeah, yeah.

And then the final question or topic. So you use LLVM as the backend in Circle, correct? Yeah, I have some others as well, but primarily LLVM. So can you maybe explain a little bit about how LLVM is used in Circle? Because I think a lot of people maybe hear about Circle and they're like, oh, it's got to just be an extension of Claim or something like that, which it's not. Right, it's not. Yeah, so it's notlaim or something like that, which it's not. Right, it's not. Yeah, so it's not based on Claim at all.

It's a completely... There's no Claim dependency. It's unrelated to Claim. LLVM is Intermediate Representation. It's like an abstract version of Assembly, and it targets a virtual machine, the low-level virtual machine, and there's instructions like you would find in an Intel or ARM assembly guide, but these are for this abstract machine. And then you emit code for this IR and

LLVM lowers it. So it's really a portable assembler. It leaves up to you the responsibilities for binary interface and kind of understanding the requirements of the operating system. It's very low level, but it's like, I just, yeah, I target the LLVM IR, but I don't have any claim to benefit. Gotcha. All right. Now.

Should we stick on? Cause we got over like what? 10 minutes, 10 minutes into this recording. Cause if we want, we can chat about, or should we switch to the next topic? There's nothing more we want to say okay you said if we want we can chat about and then there's a dot dot dot there we want we can chat about what oh like continue to talk about circle for a little bit because we're going to slice and dice this up if you want to talk about carbon uh no let's talk about circle no i i mean what I've been doing is related to that. So it's, if you want to go in that direction.

Should we? What do you think, Connor? What do the listeners want? Oh, they're hearing this. The listener. The listener. Well, I think I'm curious, you know, and maybe the listener's curious, what is the biggest difference? You mentioned the compile time stuff, but you know, if you're a company or even an individual that's using C++ right now, whether that's 11 or 20, et cetera,

you know, what's the pitch or like, you know, the things that current C++ developers might be interested in switching some personal project, or even if they're at a company to use Circle, what's the Delta, like what makes up the delta that would cause people to make that decision? Well, I'm really bleeding edge. So I'm like at 23 or 26. So as soon as there's a proposal that I think is interesting, I put it in. The universal template parameters, that missed the 23 window, but it's been in Circle for like a year and a half already. I think really the delta is that if there's a feature that a company needs to put in, they're likely unable to do that with Clang, but they're likely

able to do that with Circle. And I think really the idea is it's, I don't mind taking on special functionality and integrating that into the core of the language. I think that's good. And there's this kind of truism, which I think is not right, which is that, you know, what did they say? At the center of C++, there's a simpler language waiting to get out, something like that. Or a smaller language. I don't think a small language is a simpler or a more streamlined developer experience. And I think that getting first-class language features, which Circle as a code base is really tuned to deliver, I think that's super valuable.

And the idea that we're going to pare down a complex language that has 40 years of history or 50 years of history, and somehow that makes it more responsive to user needs. I don't really believe that. So yeah, I think really it's about trying to anticipate where the kind of work that users want...

I'm sorry. Her mom is in Virginia today. She just doesn't behave as well for me. I'm the fun parent, not the disciplinarian. Yeah, so I'm just... I'm looking for... I guess I'm still looking for that killer feature.

I think I might have found it recently. But I'm just exploring the language design space. What's the killer feature? Is it the language tuple stuff? No, language tuples are a mess. Nice, but we can get into it. Okay, so another question. Is Circle the most Is Circle the most up-to-date with the standard C++ compiler these days? If you want to try out the latest C++ 23.26 features.

It's hard to say. A lot of it is kind of gated by what's in the standard library. I mean, because what else is using these features? It's possible. I don't know. It's... I'm not even sure what's going in 23, honestly. I'm not even sure what's going in 23.

I try to keep it very up-to-date, but it's really like... It matters if there's a usage of a feature in a test case in the libc++ test suite. So, as far as standardized features. Okay, so I want to go back to,

you said you found the killer feature. What is it? Well, I think we maybe want to pivot to successor language. Okay, all right, all right, all right. That's kind of what I'm thinking about. So, we will get to the topic that Connor wanted me to discuss with him last week. What do you think of CPP, Frank? Also, wait. Should we, before we get the answer, let's just enumerate off the top.

If you're a C++ dev and you've been following for like the last year or two, what are all... I mean, Rust has been around for a decade, so that doesn't really count. And Rust is not aimed at being really like a c++ killer it just operates in the same space with different you know safety etc but there is now carbon obviously google announced in july cpp front aka c++2 aka whatever else you want to call it got announced in the closing keynote at CppCon maybe not a great naming strategy to give you two names I've seen it referred to as both Cpp2

and CppFront you mentioned JACT which is the language that exists within Andreas Kling's Serenio OS. Val is a language out of Adobe by Dave Abrahams and friends, formerly who worked on Swift. Is there any other languages or even, Sean, if you want to, you know, because apparently you've been watching from the... Right. So, I mean, carbon is obviously the biggest,

most ambitious attempt. And it's the one with the real resources behind it. Yeah. And I think it's interesting that when they announced carbon, they said, if you're starting a greenfield project and you don't have any C++ dependencies, write it in Rust. If you're extending a C++ project, you know, in a couple years you can do it in Carbon. But Carbon, the interpreter, which has no

dependencies, is written in C++. So I'm wondering at what point, like, people who say you need to write everything in Rust will actually start writing everything in Rust. Because we're not at that point yet. I actually think, so I've seen this talking point come up a few times in various talks about Carbon. And I think that

it's perhaps phrased that way because the folks behind Carbon don't want to suggest that they're trying to replace Rust or that the language in its current form, which is very experimental, is a substitute for something

like Rust. They don't want to be presumptuous. But I suspect that a lot of people who are working on Carbon hope to build a language that is, you know, yes, good for this, you know, working with legacy code opportunity. But I think they also just want to build a good language that maybe at some point in the future, that language would be a language that would be good enough to use for new projects. I'm asking, though, why not write

it in Rust? Yeah, but I think because they're C++ folks. Probably because they're building on top of the LLVM libraries. It's not on top of LLVM. Oh, you mean like the interpreter? Yeah. I don't know.

You make a good point. You make a good point. But you put a bunch of C++ people in the room, they're going to probably try to use C++. But they're explicitly writing a Rust-inspired alternative because they say Rust is better. I know, I know. So use Rust then. Like, what is this about saying C++? This is a good point. what is this about C++ I do know and I think it's okay to mention this that

at one point they were considering writing the interpreter in Swift they were considering writing the interpreter in Swift? I should know this because Connor and I have been read in on the requirements for a while

we just were observers really and i think i think there was like even an initial work in swift i could be totally wrong so like if you know there's people that are more involved in this and they're like that's not at all the case then feel free to respond on twitter but i think there may have been some initial work in Swift, but then because of the interop or something, there was some reason that basically they ended up saying that this is just going to be easier to write it in C++ for now. If we want in the future, do something else, maybe we consider that. But I think they actually did, you know, that doesn't answer,

why not Rust if Rust is better? But they did consider using a different language at one point. Yeah, fair enough. So the tenets of Carbon, I mean, they're kind of tough to swallow. So first of all, there's no function overloading by design. And I think C++ is really C with overloading. That's kind of the core of the language. There's no exception handling.

A lot of people don't like exception handling, but on the other hand, if your C++ code is potentially throwing, you're going to have to have another language that understands exceptions to be able to support that. That part, I don't fully... I think that perhaps that part of the carbon experiment has not been well it gets better it gets thought about sure uh there's no multiple inheritance now you may not care about that but i use it constantly everything in the circle compiler all the entities are expressed through is a relationships with multiple inheritance it's just something i use a lot and i think a lot of compiler people do it, really rely on that feature. And it's got no runtime penalty. It's just a way to organize classes. Right now, there's no sense of raw

pointers or real pointers. I think that's going to have to change, because when you interact with system code that's going to give you back pointers, you're going to have to change because when you interact with system code, that's going to give you back pointers. You're going to have to deal with pointer arithmetic and all of that. There's a lot of surface area in header files that have pointers for good reasons. And there's no constructors. And I think there's no constructors because there's no exception handling. So how do you return an error out of a constructor? Well, you have to make a factory function, a static member function, and that's going to have to return a pair,

like a variant with their error code or the constructed object. So in that sense, it's like Rust, but there are no constructors right now. So there's no sub-object conditionalizers, at least in the conventional sense. So the question is like, how is it going to seamlessly interoperate with C++? And I mean, that is the big, you know,

open question with Carbon. You know, the thing that, the place where Carbon offers true advantage over its competitors is the C++ interop. But that is also – that's not something that there's a prototype of today. And in some ways that is – it's not the most mature part of Carbon. Well, I don't know about that. I think Carbon, my reading of Carbon is that it's the Google C++ style guide turned into a language. And the Google style guide says no exceptions.

It says like no multiple inheritance. Like a lot of the things the style guide says not to do are things that are not in Carbon. So they may have a better experience interoperating with Google internal projects that are written according to that guy than outside users would have. So in that sense, maybe it's not a C++ successor. Maybe it's a C++ at Google successor.

Well, I'll push back on that. I think that the folks behind Carbon, I think they recognize that as a project that was started by people at Google that started originally as an internal Google project, they understand how important it is for something like Carbon to be successful, for it to not just solely be a Google thing. Why? Because I think it is a few reasons.

One, if you only have one major organization investing in a thing and only one major organization having ownership over a thing, it becomes very tailored to that organization's needs and uses. And that puts like a cap on how far it can grow. But we're talking about Google. I mean, it's a country unto itself. Yeah, but like they specifically don't want it to be a Google-only project. They don't want it to be perceived as a Google-only project. And it's not. It is admittedly true that many of the core collaborators are folks at Google,

but they've gone to great lengths to build a wider community. And I'll say this, the thing that I see the greatest potential in in Carbon is its governance model and the people behind it and their goals. So I agree with the goals that the programming language has. And I think that more important than where a particular programming language is today, to me, is how that programming language is managed and how it evolves. And I have a great deal of confidence in the evolution process that they've set up and in its ability to address these problems over time. I think if Carbon is successful, what Carbon will look like in three to four to five years when it starts to become successful will be very different from the shape that it is today.

I'm just going on to what the current design docs say. But I think that they have set themselves up for success and that they have put good institutions in place to allow them to evolve what carbon looks like today to something that works for the audience that they have in mind and achieves those goals that they have in mind. Okay. So on the flip side, I mean, I enumerated all these things that carbon removes that C++ users expect to have, like function overloads. Yeah. But they, I mean, they want it to be a good user experience.

So what are the things they're adding? And a lot of these are Rust-inspired things. Like instead of function overloading, there's like concept-based overloading, or what they call like Rust traits, or in Swift, they're protocols. And in C++ prior to 2011 they were concepts. You know they're putting a lot of investment in these interfaces or these traits. The other thing is some types they have have a choice type, which is just like the Rust enum, and they have a first class tuple. And so when Carbon was announced, you know, I thought like, you know, what is getting the developers excited about this? And it seems to be this new set of features.

But all of these things can be implemented in C++. Especially something like a sum type, a language-level variant. It's really easy. It's just another data type. It's just a tagged union with some compiler-generated constructors and assignment operators. So I implemented that pretty early on, after the carbon announcement. I implemented the question mark operator from Rust, which is the propagation, so that if you have a choice type called result and has an okay field and an error field, you can use the comma operator. And at runtime, it'll examine the active element of the choice type, and it'll either yield the okay element or it'll return

the error. And this is a way to propagate errors without exceptions. And this is what you need when you're using these factory functions. Since you don't have constructors, a factory function would return a result of that type, comma, whatever the error code is. And then you would be able to use the comma operator to chain the propagation and without a whole bunch of typing, have a kind of static exception handling. There's syntax for first-class language tuples. So it's just like comma separated list of types

or comma separated list of expressions. And then finally, there's concepts or what Carbon is calling interfaces. So it's not to confuse them with C++ concepts. So I went back to the archives to like 2007, 2008, and I dug up the old C++ OX concept wording. It's like 100 pages of wording, Doug Rager, mostly Doug Rager. And there was like, there's the Indiana school and there's the Texas, University of Texas, I guess. Yeah.

Right. And there was kind of a, after a few years of back and forth, they had a kind of a joint proposal for this. And it was merged into the language. And then I think in 2009, it was all removed. And then we went without exceptions until C++ 20, and then they were without concepts rather. And then concepts we got were concepts light, which are basically just porcelain around enable if. So it's really kind of gutted the feature. But that concept

feature from 2006 is exactly what Carbon is staking really its entire core on, which is how do we do overloading and how do we do generics? And for them, they said, we want to have these C++ OX concepts. They use the term interface to keep it distinct from what concepts are in C++ now. So I've been implementing that and it's been like really difficult. But I think collectively, I have more confidence that these are the features that users want to see because these are the users that, these are the features that persuaded Google management to be able to, you know, say, we want to fund this experiment and see where this experiment goes. And you talk to a lot of other

kind of C++ old timers and they, they are really like Dave Abraham at CPP Now. He was still agitated and angry about the removal of concepts back in 2009. There was this large schism you know it's possible that uh you know the folks like doug gregor and dave abrahams who went off to create swift would have still been working on c++ yeah i think i think this was a a major defeat as far as like losing um you know senior senior leadership. Yeah. Yeah, and I think for some of this stuff, we have to like... I think the committee process has been not optimal for C++

because people really... People really go to the mat. At the beginning of the episode, the cold open. I think a lot of the voters, they go to the mat about what... If they like a feature or not. They think it's a good feature. And that's important, but that's not the only concern.

I think keeping the community together is another concern. And that's something I've learned writing a compiler. A lot of the features I implement are not things I care about particularly. Like these generics I'm putting in, I don't really care about C++ OX concepts or Rust traits. But I know that a lot of other people really care about them. I mean, they really care about them. And I'll believe them in that and I'll put the effort in to make that happen. And I think it's kind of important that we give other people who've over time proven themselves to be thoughtful, capable people,

we need to give them the benefit of the doubt and say, if they're really interested in these features, we should put that into language, even if I'm not personally into it. Because otherwise, it prevents the language from moving forward. We're never going to get 100% agreement on really anything. So I think we need to kind of like give ourselves, you know, more of a benefit of the doubt when it comes to adopting features. The language won't evolve otherwise. In doing your historical deep dive,

was it documented why they ended up getting rid of them? Obviously there was folks on the committee that obviously weren't a fan of it. What was the justification? Buddy, you're going to have to... that's a whole another episode where we get we get some people from that time period on to talk well i mean i i was curious

too just from a technical standpoint because like the wording they have isn't i mean it's it's okay it doesn't answer all my questions and there's really nobody to go and ask anymore because we're talking about language that's 15 years old. I think there was an issue, a disagreement, between like Bjarne's camp that wanted implicit concept maps so that if a type is probed and this type is determined to satisfy the requirements of the interface, then it satisfies the interface as opposed to explicit concept map.

It's just like a choice of defaults. And I think there were a lot of those. And then the time was running out to get something into 11. And at the end, instead of getting consensus on what the default should be, the rest of the C++ committee members just decided to remove the feature. They're like, well, the clock's running down. We don't want to ship something that we don't have consensus on. So they removed the feature, and then they never really got back to work on it.

At that point, they just moved on. I mean, I'm sure there's a lot of interpersonal conflicts. conflicts? I think there were but it was a combination of a variety of technical disagreements and then those led to a variety of interpersonal arguments and I think it reached a point

where both camps became very entrenched and there wasn't really a compromise to be found. I tend to not particularly like the design of the concepts that we got. that the OX concepts design was much more natural and much more how I would imagine. Like when I write up in like comments, like what a concept should look like, it's much, you know, like I define sort of like the, you know, the archetype of what it would look like.

And that's much more what the C++OX concepts look like. Whereas with the concepts that we have, you have to write out these examples of how it'll be used. And I just find that supremely weird. Well, the concepts we have now don't do type checking at definition. That's the big difference. Like, Rust traits and what they're trying

to put into Carbon, which they're calling Interface, and the Swift protocols, which is actually separate compilation and there's a runtime penalty for using the generics in Swift, but the general form is the same. That type checking is done at definition. So you write your function generic and each of the

template parameters, the generic parameters subscribes to some number of interfaces. So it says like, this is an input iterator and that input iterator has a bunch of refinements indicating, you know, it's regular, it can be copied this way, and it has these operations. And only those operations that are parts of the interfaces for each of the data types can be used inside that function. If you use any other thing, then you get an error at definition. Yeah. In C++20 concepts, the concepts are just an enable if check. So if you get past that function declaration into the body, the concepts at that point are moot. They're

not operative anymore. I think the question of whether we could do type checking with OX concepts, that was really sort of what killed it, was that they um that it would become impractical or computationally impractical or something to that effect um or the or it would be too complex um but then we ended up with this concepts light and without and you certainly can't do type checking in that model um but without that what's really the value of concepts? Like it doesn't really seem to me like it delivers anything more than a smarter enable if. It was promised that it was going to give us

these better diagnostics. And I will admit the past like year, the diagnostics have gotten slightly better, but it really does not, I think, substantially enhance the diagnostic experience in the ways that we thought it would. And yeah, I don't really see what the tangible benefits are other than it's a cleaner way to do enable-if. I don't think we have to worry about C++20 concepts

because we have evidence coming from these successor languages. Swift has the protocols. Rust has the traits. And now there's like a decade of usage experience where the customers are more or less satisfied with that, with that kind of contract between the function and the caller. And I think it makes sense now that we have, you know, so much usage knowledge to try to go back and implement that in C++. So what I've been doing is, like, I have archetype establishment, which is when you mark up your function template with all these interfaces, it's the conjunction of these interfaces indicating the capabilities of the types, that is hard to use internally.

And I think the problem is that if you were to specialize a class template over one of these archetypes, in the current C++ scheme, you can't use any of those member functions because those member functions are only known once that class template is specialized with real types, which is during instantiation. Because you don't know if it's going to hit a partial template specialization, if it's going

to hit an explicit specialization. So I've been going through and creating new kinds of fundamental data types. So I have class generics and choice generics. So if you have a template with the template parameter list class foo, that's the regular class template. But if you have generic with the template argument list class foo, now foo is a class generic. And that has a guarantee that there's no partial or explicit specializations and it allows you to um to see the

uh the the members of that class at definition so i think the problem is that and maybe this was a problem back 15 years ago was that c++ didn't really have the full vocabulary to support um early type checking in a way that was convenient. But I think a lot of the decisions for generics in Rust and Swift, and I'm sure Carbon, when it kind of shakes out, is going to limit partial specialization and explicit specialization to allow you to fully type check the data members of a class that you're using inside a generic function. So I've just got a whole bunch of things

in flight now to try to bring the new features that are promised by Carbon into C++ without having any concern about breaking compatibility. It's all embedded in existing C++ compiler. And what's your motivation for doing that?

My motivation? Well, I'm always looking for features that are going to... That are going to bring you users, yeah. Yeah, that are going to be the hit feature. And I think that... But is your point also that we don't need a successor language because we can make C++ better? I don't think that's my...

I mean, that might shake out. I don't know. But it kind of is up to the people who helm those successor languages. Because if these successor languages work really well, then they can speak for themselves. I'm just speaking for my evolution to C++. And I think that C++ gets a lot of flack. But I think we can still evolve it in any direction we want.

If we wanted to put vowel-style value semantics in it, I think we could do that. I think we could evolve it in really almost any direction and still retain core compatibility with all the code out there. Yeah, I tend to agree with you. I think most of the C++ committee and most other implementers don't. Why do you think so few people see the potential for evolving C++? Well, they don't want to have to do 20 years of proposal revisions. For some of these features, they would take

forever to get through the committee. And it's easier for one person or a small group. The Google people, who were already the major claim maintainers, could have just forked claim, and they could have built the carbon features straight into claim. And they could call it a successor language.

That's fine, but it would have been a super set of C plus plus. Yeah. It could have had a new syntax. They could have, even if they wanted made a context for a new context, free grammar that has not even all the features, but still plugs into the existing compiler.

Yeah. Right. Now I think that's just a different workflow, but it's one where at all points you can keep compiling a C++ hello world and you know it's going to work all the way through and you can make your incremental changes and you can evolve

it in any direction and I think you know that's what I'm doing and having a really nimble C++ compiler source base you know allows me to do that and I think that's really the value. But you also don't have a committee of 300 people that you have to get to sign off on. But the clang maintainers don't have to do that either.

They could have just said, we're going to fork Carbon. And Carbon is going to be basically clang with these other features. They didn't do that. Why don't they? Well, I don't know. I mean, they have a different strategy. I mean, they think differently of C++ than I think of it. Right, because I think they would argue that's not C++, that's C++ with extensions.

Well, okay. What's the difference, though? At what point does the circle dialect of C++ become its own language? This is – I don't think this is a – this is just a vocabulary distinction. I don't think it has any – it doesn't affect anything. What matters is if you're a company and you've got billions of dollars of value in C++ source spaces, you want to keep compiling that. You want to make sure that every year you get the new version out of the new build out. And it'd be great if the compiler improves with your own software. And we can do

that. We can evolve C++ much more quickly and actually give users the features they want without having to break anything. Or if you do break, it could be a tiny small break.

I've gotten a lot more bold about my extensions recently. I've realized I have this pragma, like pound pragma feature and feature name. So I have one like pound pragma feature generics, pound pragma feature tuple, a couple others. And what they do is they draw new tokens, but only for the file. So I can pound pragma feature generics and then include any STL header. And I know it won't conflict with those new tokens I brought in because the token scope is only in that file and I can turn it off if I want. And now I realize, well, why not just like, you know, evolve really rapidly.

I know I'm not going to break anything because the syntax is gating or that pragma is gating which source lines are exposed to the new features and you know you just try it out I keep turning it over and over and so I've been turning over these function generics, the class generics tuples, choice types and I'm

just trying to go through the checklist because I think on every metric an extended C++ can be competitive with the new features that Carver wants to offer. Without any question about, well, it's not going to support exceptions. It's not going to support, you know, function overloading. Yeah, for me, this is the way to move forward. And I'm actually happy with the successor languages because it means there's other people thinking about what features are important, and then I can go and implement those in my own system. Yeah, so I do agree with you. in practice in the field some of the ways in which

we would evolve will become constrained by actual real world impacts of making breaking changes but I think that the C++ evolution process has essentially become paralyzed

by this fear of what will happen if we make a breaking change. Why is everyone so fixated on breaking changes? That's a good question. I mean, none of this has to, like, interface generics, right? We can Why is everyone so fixated on breaking changes? That's a good question.

I mean, none of this has to, like, interface generics, right? We can put these in, and that doesn't break any code. Some types don't break any. People want pattern matching. But doesn't it introduce new keywords? Yeah, so what? Like I said, I'm gating those. Pound, pragma, feature, interface. Your source file.

Your new source file, put that in, right? You don't have to worry about all your system dependencies. This is a successful approach in other languages. Doesn't JavaScript do this? Don't they have... You're the programming language person, Connor. I expect you to know this.

I don't know anything about JavaScript other than they got 17 different ways to compare things and what everyone whines about is triple equals, blah, blah, blah. No, I believe JavaScript has a new strict thing that if you do it, it gives you more modern...

I just think there's been too much made about ABI breakage. I don't mean ABI breakage. I just mean evolved... Yes, that's a problem, but I think in a lot of the cases and examples that you have in mind, it's not a question of ABI breakage, I just mean like, you know, evolved, like, yes, that's a problem, but I think in a lot of the cases and examples that you have in mind, it's not a question of ABI breakage, it's just you're introducing new syntax, new... Yeah, so, but what's

the problem? It doesn't interfere with the old syntax. See, I don't have, I don't see a problem with that. And in fact, there have been language proposals for a thing called Epics, you know, in this space. And I think, at the end of the day, the problem is just that the C++ evolution process moves so slowly.

I think epochs, I mean, you can debate about what should go in the new epoch. And I think that's really probably where it would slow down. Like people think something, what is best? I don't really believe in codifying like best use, you know, best practice.

There's another reason why I think you'll get resistance from the committee. I just remembered this. There's this fear of creating dialects. There's this fear that if you have like these modes that you opt into, then C++ becomes

sharded into multiple different dialects of C++. I personally think that this is not a dialects of C++. I personally think that this is not a reasonable argument because we already have dialects. You've got CUDA.

Yes, you have CUDA. But also, you know, between C++ 11, 14, 17, 20, like in the wild, people program in these different time snapshot-esque dialects and and introducing some epics like thing or some some pragma feature thing that lets us introduce new syntax in that people opt into it would just be another form of that um so i don't understand the the concern for that but i think it's really it's a concern that like there must

be one unified c++ um and i think i think there are some people who view c++'s devotion to um uh to backwards compatibility at all costs as just like a core aspect of C++. Again, I think this is a I'm trying not to, again, when I see a can of worms, I don't go and open it. I wasn't going to take a bite about this earlier, but we

got to go back to that. Dude, you built your own C++ compiler. That's like by definition opening up a can of worms. Well, no. I mean, it's something you can make consistent progress at if you just push at it. And this thing about, well, this existential crisis

about breaking compatibility with old code or breaking ABI, I don't, I'm just, I'm not personally that interested in that fight. I could go either way. I don't care. If somebody wants to spin a new libc++ that has different data layouts or types in the same namespace,

all right, it's just something to point the compiler at. For me, it doesn't really matter. I think we should let the vendors do what the vendors are going to do. If you're on a managed Linux system, if you're on a CentOS kind of system where you have a professional sysadmin who rolls it out every three years to the organization like that's a fine time i think to break avi if you're going to do it because it's like the whole organization goes in one goes as one unit and then you all debug your problems and then the next month you're back up and running you know I there's ways

to do it but I don't think that saying well we have to break ABI or we have to break backwards compatibility to evolve and there's we can definitely evolve without breaking full code right I agree but the problem is that it requires us to take

bold steps to do is that it requires us to take bold steps to do that. Or it requires the committee to take steps that the committee thinks of as bold. I don't know. The reality is that it takes 10 years for any new idea to get into the standard. And so it would take 10 years for us to get pragma feature or epics. But I mean, by saying pragma, I'm indicating I don't really care about standardization.

I've chosen a vendor extension there. My point is just that if we just assume that there's really... My point is that even if all three of us here agree that this is a thing that's pretty straightforward,

there's no real reason not to do it. And even if most C++ programmers would agree that we should have something like some mechanism like FX or Fragment feature that would allow us to model language better even if everybody in the committee agreed upon that

and I'm pretty sure that we've taken polls to that effect it would still take 10 years for us to hammer out the details on the committee Right, but the committee, I mean, at the end of the day, companies want to keep compiling their software and make it incrementally better and then sell it or monetize it somehow. And I think for them, what's more important? Is it adhering to the ISO standard or is it being able to compile their software and having confidence that they'll be able to compile it next year as well?

And I think we've conflated the two. Companies have gotten – they're confident that C++ is a long-term thing because it has this international effort behind it. But at the same time, we know now and we're feeling the pinch of Google withdrawing, apparently, quite a bit of investment from Clang. I mean, it seems the pace of Clang development has slowed down. And maybe they're shifting to the successor language. And the interoperability story there is very questionable. So if the question becomes, well, we either jump to Carbon, whatever that may be in the future, which really there's no there's no guarantee to continue to compile our existing code. Or we just suffer with C++20 or like, you know, very slow incremental progress and bleed users and like find it harder and harder to recruit developers.

Like those are like two very risky propositions. And I think that the less risky one, which you're right, it's not going to sail through ISO standardization, is to take the ISO standard, yeah, honor it. Like, yeah, I want to implement everything that's in it, you know, and then just give the features that these other rival languages are providing their users. There's no reason we shouldn't have a some type. And you know that. It sounds like you are essentially calling for revolution.

No, I'm not calling. What is with this? Connor, do you have to do this with Bryce every time? No, no, no. I mean, I take the most conciliatory tone possible, and he's saying I'm Rose Pierre over here or something. But if you unpack what you're saying, what you're saying is that we should just take ISO C++ as it is, and then compiler vendors should build the features that users want.

That's not revolution. The standard committee can keep making, on a three-year cadence, can keep coming out with a standard. That's fine. And if you're on a team, the project manager of the team could say, well, keep with the standard. Keep with 17. Keep with 20. Keep with 23 or whatever. Or they could say, well, just use this set of new vendor extensions, whatever.

But what people want is they want to be able to – people are afraid of vendor extensions. They want to be able to take their code and use it with any C++ compiler. But that's not the case with Rust. There's one Rust compiler. There's one Python compiler. There's one Swift compiler. There's zero party compilers. Every other language has just

one compiler. Are you advocating even more interesting position of that we should just have one C++ compiler? No. Unbelievable. No, no, no. But why not? You have such isobrain. No, no, no, but why not? You have such isobrain, it's... No, no, but why shouldn't we have one C++ compiler?

Look, because if that was the case, I would never have been able to write mine if there was some law where... I'm not saying there should be some law. Some enforcement mechanism where the SWAT comes in and like... Well, if we're going to have one C++ compiler, it should be circle. Oh, well, yeah. Great. Great. No, I think it's important that everyone...

Look, I'm not against the successor languages. Yeah? I think, you know, they say carbon is an experiment. Like, good. I think the scientific method of trying things out and trying to learn from that is good. I want to do what they're doing to learn from that is good. I want to do what they're doing, but from a different direction. For me, compatibility is really important.

For me, I'm extending ISO C++. I have the same features that Carbon has in mind, and I'm just putting them into the C++ compiler. Okay, but what if another compiler wanted to really like one of the features that you were doing and wanted to put it into their compiler?

And then they wanted some mechanism, like, by which the two of you could agree upon how the feature works. Okay. That would be good. That would be, that would indicate a lot more, like, ambition and creativity in the C++ compiler space than there is now. Yeah. more like ambition and creativity in the c++ compiler space than there is now yeah i mean i think there i think maybe you're saying the committee is afraid of like too many people

doing creative things is this what it um but that's like not that hasn't been the case really in 20 some years committee's afraid of too many people doing too different too many things um i i think the committee wants to to be bolder and the committee wants to be bolder, and the committee wants to do creative things, and I think pretty much everybody in the committee has good intentions. I think the committee's problems are that there's, one, there's just too many people. There's too many perspectives.

I don't think that you can have your core decision-making body be like 350 people. I think there should be like eight people at most that make final decisions on things. It's not that there's too many voices hearing everybody's opinions is good but there's too many there's too many like deciding voices um and i also think that there's like because of that there's far too many constraints because like we've got like 350 folks that you got to convince um and and everybody has like very different goals and objectives um and you know our goal is to build like you know we're all built around this building consensus and so i think oftentimes we bend over backwards

and try to satisfy you know whoever happens to be objecting loudly to what we want to do. And it ends up where you've got this thing that is pulled in 20 different directions to satisfy these constraints. Yeah, I think that's how it plays out. That's probably an accurate dynamic. You would know, I'm not involved with any of this. But on the other hand, when there's a new proposal that's like a core core language proposal you know i if it's if it seems to me like well defined i will implement it yeah and

even if i'm not that interested in it and i think that we should have a more liberal attitude which is i was saying at the beginning of this even if it's not about standardization as the ultimate goal but it's just like like the talk i gave in in Asperger's. Like you said, you're, you're angry that a lot of people had objections to it. I, I felt that it was such a good, the issue that I had is that I think people fail to appreciate, um, the, the vision that you have and how much you've driven forward

the world of C++ compilers. If for no other reason than by demonstrating to people that it's not some big, scary thing that there's only three people in the world

and you need these huge teams to do. You're just one guy who went off and built the C++ compiler. And when you find a proposal that you find interesting, you can go and rapidly prototype it. And I think it's been very refreshing and eye-opening for the C++ world to see that that is possible. And it, it,

not everybody, I think I, I certainly, I don't agree with every aspect of your vision of, of the specifics of what you have in mind. But it seemed like to me, like that was sort of besides the point that you were showing us a world of possibilities and you don't have to agree with every possibility that sean showed in that talk but that world where we can have all these possibilities that's very exciting and then a bunch of people came up and

asked questions nitpicking like well i don't like this and that and that and it just it made me so sad because i'm like but you're missing the point the point is that we have so many options that we can move faster, we can explore all of these things, we can make the language better. And people just wanted to focus on the language. Yeah, I think I said something like, I'm not trying to convince

you of any individual feature. I'm just trying to convince you that incremental change will make the language better and more expensive. Right, right. And what made me sad was that people didn't focus on that. People focused on the rules. Well, I think it's just like, take a beat. You know, like, I delivered like 90 minutes of like rapid fire.

It was like, here's like 20 new features, right? And just like sleep on it at least. And try to look at it from a different angle. Because I think there's a lot of preconception about what metaprogramming should look like. And my stuff didn't look like that. It might have looked more like JavaScript or something else. I mean, I didn't really have any individual idiom. I was just trying to do things that would cut through the nonsense we deal with on a daily basis if you're writing standard library code.

And in that sense, it was very non-ideological. I was just trying to get to complete the problem, finish the problem. I think people just need to adjust their brains a little bit to sit back and say, does this help me

solve my problem, as opposed to, does this conform to some design ideology? I think for a long time, C++ has does this conform to some design ideology and i think i think for a long time c++ has been too much in that design ideology mindset whereas other languages they don't have these scruples really yeah like if there's something that's super useful like they'll put it in there even if it doesn't make any like theoretical sense and i know it going back to the epics i think the epics thing is a perfect example of that. One of the biggest objections to Toons and Minnick epics has been this ideology that

we can't have dialects or subsets of C++, that it needs to be one coherent vision of a language. And I'm sure that there's a motivation for that, um the the sort of the absolutism of like that keeping us from doing the possibly the one thing that could really unlock our future is i think very uh very troubling and and it's the way that i've heard that concern expressed has really been sort of this like theoretical, well, you know, we might shard the community in the future if we introduce some notion of, you know, subsets or variants or dialects.

And so we shouldn't do or encourage that. And there's a lot of things like that where the committee is presented with some option and that option would fix a real problem that we have. And we don't do that thing because of some theoretical problem that might happen if we do that. And it's like, the house is on fire, but we don't want to put up the fire because you know that could create some other problem well maybe we should focus on the problems that we

have there are i think also we lose sight that there are you know like a million full-time c++ programmers and it's their livelihood yeah and um you know if you can make them incrementally more productive, you can make them 5%, 10% more productive. That is like industry changing. That is when you integrate over all of the effort going in, that is, you know, so many billions of dollars of value added. Yeah. And I don't think we should like, you know, veto features without really considering the consequence of what we're doing there. But one of the sad things, and I think you will be intimately familiar with this, is big tech companies so drastically undervalue developer productivity. And this is one of the reasons why there are so few like compiler front-end

engineers relative to you know compiler backend engineers um this is why like you have so few people working on um uh like standard libraries and build systems and stuff like that because um at the end of the day a lot lot of big tech companies' perspective is like, oh, well, you know, it's painful to write the code. Like, that's okay. Like, we've got good developers. Like, they'll be able to do it. And it's like, it's exactly what you said.

You know, if you make all your programmers 5% more efficient, that is going to save you so much. And it is sad that, it is sad the degree to which thing technologies like compilers are undervalued um uh you know especially in this day and age there used to be a lot more you know c++ compiler companies and um now there's really only a few there's only really one front-end company left that's EDG.

There's just not the money in the developer tool space that there is in other sectors. If I go to a programming language conference like C++ Now or CppCon, back when I went to CppCon, you go and you see like who's sponsoring it and like how big like the vendor space is and it's not that large. And then you go to a conference like supercomputing or like a conference that like sells where they sell hardware and it's like there's so much fun in it. The whole exhibition hall is been yeah yeah switches and things yeah um but it's just we just don't we don't we invest in the physical tools that we give to programmers we don't

invest in the uh the um the software tools that we give to programmers as much as we should now okay but you but you never answered the question what do you think of cpp yeah well so i was gonna say we've been talking about, um, carbon and circle and C plus plus. So I guess first question is, did you watch the closing keynote? And then second question. Yeah. Thoughts on CPP front. And, uh, hopefully the answer to the first one is yes. And then you can give a little, cause I'm sure that some of our listeners have no idea what we're talking about because they have not seen that keynote yet. I did not watch the keynote. Wait, wait, Conor, did you watch

the keynote? I did, yes. Okay. I participated in Herb's keynote from the previous year where he showed the pattern matching proposal which I implemented in Circle and after I sent him that code, he sent me the CPP

to doc which is not public and that's like 120 pages so I read the doc so I have more information than wait so what this was back at right after last year's CPP gone maybe before like probably in August of last year interesting because this is a uh what do you call it, an editorial comment that I had sort of, I thought that this mostly was a reaction. Oh no, this has been, I mean, CPP2 has been around for like a while. Herb's been working on this for a while. I think I first read of it in... Herb should have, he should have done this announcement like a couple years ago. Well, this is, I think, I think there's always like this, this challenge when you've got this new project, like when is it ready to show? Well, it's not ready to show,

but you should show it still. Yeah, exactly. But I think that that's really hard for some people. Yeah, it's fine. Yeah, but I think, you know, Carbon, I think, picked a good sort of time. One thing that Carbon did was, Carbon didn't

go public as soon as it was conceived of, but they had a pretty long period where they brought in more and more. I think Carbon was too early announced. You think it was too early? It didn't even have not equal operator.

It didn't have less than. It didn't have integers other than 32-bit. It didn't have floats. It's not like a... It can't compile anything. There's no compiler. I think they should have got cogeneration. But I agree that CPP2, I think, would be far more effective and more likely to gain traction as an idea if it had been announced earlier.

I think ditto with things like metaclasses, etc. Yeah, because I looked at the repository and it started in mid-2021 or late-2021. And almost all the code contributions happen since July. So just like three months ago. So when I was talking to her, he had just started, like this was last summer. He had just started that repository. And like he said, it's, it's a,

I guess he's calling it a transpiler, but it doesn't like, it's not a compiler. So it's a one way, it's a one-way, it's a one-directional thing, which is not, you can't actually make software that way, right? Like, textually, if you call a function, you have to know what the result object type is of that function. There's no way to determine that from this architecture he has. So it's really just a way to show the syntax, I think.

The more of the, the real values in that document, which I don't think he's made public still now. Yeah. So that is, I guess this is kind of the same. I'm not going to say criticism, but I'm going to say this is a different philosophy I have from carbon or from CBP too,

which is we can, we can disaggregate these features like Herb's feature, major feature, I think is the parameter passing. He has these directives like, you's major feature, I think, is the parameter passing. He has these directives, like in, in, out. Yeah, yeah. And they may compile to different things. They may emit an R value reference, or it may emit a deep copy or a pass-by value if it's a trivial type.

You can disaggregate that, and can say, this is a C++ proposal and we can put that into an existing C++ compiler. And it's just a few like new bits of syntax. And I think that's, if you want to show like that this is a better way

to pass parameters that leads to less bugs, great. And let's fold it into existing code and we can even rewrite just a map or something like that with these new parameter directives. I kind of wish that he had focused more on the features, to disaggregate the features of CPP2 and focus on the individual. And he has kind of.

He does have a proposal for static exceptions. And I think there's that yeah there is a metaclassical proposal although these are again like five years ago which is when he started this this grand vision i think it's kind of like um you know rodan you know like the whole gates of hell tableau but like people don't want the whole tableau they just want the thinker so you know herb just like give us the thinker. And the whole tableau is a little bit much to buy into. If you care about it. And just in case our listener is not up to date with this announcement,

basically this CPP front slash CPP2 thing is, I don't even really know if it's, you can call it a proposal. Herb in his talk says that's just his sandbox or, you know, for, you know, it's his can call it a proposal herb in his talk says it's just his sandbox or you know for you know it's his sort of dreamland future where he's introducing a whole new syntax and then calling it not a language but as sean mentioned like it transpiles to c++ and it's just a different file extension so you you know write this new syntax, call the file dot CPP two, and then it'll generate a dot CPP file, which then ends up getting, getting compiled. And there's a bunch of new fancy stuff, the inode stuff that just got mentioned, which if you've

watched Herb's keynote, I think from the previous year, a couple of years ago, he talked about that potentially being something that could show up in C++. um yeah he unifies i think like function and lambda syntax and there's a bunch of stuff in it yeah and it's i thought the most i don't know the most curious thing but at the beginning of the talk and it might might actually be like the most i don't know what the word is concerning but i was just like wow it made me think of java from 2018 when i was at oracle hq for like a java 13 party and one of the people presenting on stage who is like a key java contributor i can't remember his name i can find it and put it in the show notes he went on a big he got a question from someone in the audience about like some feature in scala and then he went on like a 10 minute monologue of how you know java's not dead

and you know you can't keep just asking for all these cool features and these functional languages and i was just like, whoa, man, like it was just a question. Like, why are you getting so upset just because someone mentioned Scala? Cause I'm guessing clearly these people that work on Java get a lot of questions. How come we can't have language X language feature X and in job.

And so what Herb said at the beginning, when maybe I'll even, I'll cut the audio clip in, uh, is he basically begs the audience. He says, please don't leave C++. And I was like, wait, what? You're at a keynote talk of the largest, or I guess maybe not by this year's numbers.

But, you know, it's sort of known as the, for however many years, the premier North American, I guess it's only one of two, now three. Anyways, point is, it's a big conference. And the closing keynote is like asking the attendees of the conference like that, that was being, cause like, and like I said, like as soon as he said that, it made me think of like this meetup that I went to at Oracle HQ where, you know, the, this guy was basically upset and saying, you know, Java's not dead. We got millions of people, blah, blah, blah. And I was like, well, I mean, the second you start saying something's not like, it's like, you know, when they say, oh, smart people don't say they're smart. You know, it's like, it's one of those things it's anyways it was so like i said i'm not

sure if the word is concerning but i just i i thought it was odd to um and that made me even think is like is this like actually like some inflection point and is it the beginning of the end we're seeing all these suggestions i think it's definitely an inflection point. I think whether it's the beginning of language space is going to, is everyone going to be writing in circle? Is it going to be C plus plus is just going to be in slow decline or tune in next time to hear Sean's answer and part two of this episode. Thanks for listening. We hope you enjoyed and have a great day.