Herb Sutter (Clip) 0:00

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.

Conor 0:32

Welcome to ADSP the podcast, episode 97, recorded on September 25th, 2022. My name is Connor, and today with my co-host Bright, we talk to Sean Baxter about Carbon Circle, and CPP front. We've got uh bidirectional is the infinity sign, omnidirectional is the circle, stereo is the overlapping Venn diagram, and cardio's the Okay, which one do I want to be on? Probably Omni or yeah, omnidirect.

Bryce 1:06

Connor, Connor. There are four circles. Oh, yeah, right, right.

Conor 1:09

The circle, the circle, the circle. It's it's topical that this is a perfect segue into having Sean Baxter.

Sean Baxter 1:21

Better not be puns involved.

Bryce 1:23

Woo! Alright, so we should uh we should introduce our guest.

Conor 1:28

Yeah. Bryce, you take you take you can take this introduction.

Bryce 1:32

Uh hang on, my my dog is is staring dead into my eyes right now. Alright, I am here in my lovely Manhattan apartment with Sean Baxter, co-creator of the circle compiler, which I personally think is the future. Um Sean, maybe you should introduce yourself.

Sean Baxter 1:55

Uh thanks for the introduction, Bryce. Uh um here to um I guess for a really aggressive interview, it sounds like adversarial one. I'll try to stay in my toes. Yeah.

Conor 2:09

Did you listen to the last episode? Because what happened when I'm not even sure I'm allowed to mention it, but we Bryce uh 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 uh about uh sort of successor to C kind of area, and then he was like, Oh, do you mean jacked? Or no, first you 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, uh, 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.

Bryce 2:52

I think I think more importantly, before everybody decided they wanted to make a successor for C, probably predating it by like three or four years, Sean decided he wanted to make C better.

Conor 3:05

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 CPP cast and one on CPP chat. And I distinctly recall being in uh 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 uh you were and then I think it was like I can't remember, yeah. If it might it was probably the CPP chat one, and the and the 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, uh, scores of people, and you just did it single-handedly. So, anyways, you can uh right.

Sean Baxter 4:05

So, it's been six years now that I quit my job. I have this uh epiphany about um 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 that 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 uh evaluate it through the interpreter at compile time. And that way all the standard library and and pretty much all code would be available to you uh to use for compile time programming. Uh and that was that was the impetus. So I have a like a meta token that you can put in front of a statement, um, and it'll uh evaluate that and create that object um at compile time. And there's no like, it doesn't care about constexper or anything like that. So you can have mutable state, um, and it kind of blurs the line between a compile language and an interpreter language. It's still statically typed, it still generates uh object code at the end, but now you have um access to a 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 um kind of reflect on that data to emit code programmatically. Um 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 um use the interpreter and evaluate my own uh 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 uh STL headers, I'll try to consume you know other kind of open source projects to get this thing um uh built, and then instead of worrying about uh emitting object code, I could just run it inside the compiler, and that was a good way to bring it up. That's pretty pretty amazing.

Bryce 5:59

So, but I I wanna I wanna I wanna go back to the the the first part of that amazing story, which is you quit your job. You believe in this so much that like it just just just take me through that. Like you you were had such conviction in this that this needed to be built.

Sean Baxter 6:17

Um Right. Um I I I 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've 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 I try to stay productive and I just try to write code, and I have this sense of like just being able to cruise through any issue. And I I think I've always had that kind of conviction. It's just a matter of willpower. So if I if you have the idea and there's an idea that's attractive, and if you can sum it up to willpower, then you should go and do it. I didn't have any other you know dependence or anything like that, so might as well follow my dreams.

Bryce 7:14

That makes things a little bit easier.

Sean Baxter 7:15

Yeah, but I I think since then Circle has um evolved a lot and it's gone in a lot of different directions. So I have um I've had two distinct pattern matching implementations. I've had um a shader, I embedded the uh GLSL OpenGL shader language into C, and I can emit uh the Spearby intermediate representation, which is used for um Vulcan and OpenGL code. So you can program uh any of the 12 shader stages in C just like you would CUDA. Uh I have like a CUDA to target, um, and I've been at uh CPP now, I I gave a keynote on uh pack uh meta functions and enhanced parameter packs at Joe.

Bryce 7:57

It was a great talk. I loved the talk. I was s I was sad when people had so much constructive criticism afterwards, but I thought it was a great talk.

Sean Baxter 8:08

Yeah, I mean I'm just I'm just trying to explore um 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 things that they're not things that are likely to be um standardized.

Bryce 8:23

But are they radical or are they radical for C ⁇ ? And like I asked 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?

Sean Baxter 8:39

I don't know. Um It's hard to say. I mean we we are where we are.

Bryce 8:47

Yeah.

Sean Baxter 8:48

Um yeah, so uh do you want to like pivot to the uh successor language question?

Conor 8:53

Because I think that is I have a few uh 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 uh this in of this interview here.

Bryce 9:06

Okay, so so so next uh uh next discussion part. Um so Circle is not open source.

Sean Baxter 9:14

Right.

Bryce 9:15

And I think a lot of people maybe find that surprising um in this day and age. Um can you maybe explain why it's not open source?

Sean Baxter 9:22

Um Yeah, I don't want to have to respond to people. Um I 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 um demands on your time, and you know, this is still like a research language, even though it's a full compiler, it's 275,000 lines. I've I've run a lot of test suites through it. For me, it's still about exploring ideas. And you know, for me, I want to spend my time developing ideas and I think responding to to users to like and they have like all there's so many, there's so many odd demands that I 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. Um this is giving me more freedom to kind of build the tool and take it any any which way I want.

Bryce 10:25

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 and it's just a big commitment to support um kind of a community, even.

Sean Baxter 10:38

Yeah. Um even if you just have like few contributors, it's still uh a demand on your time. And you know, I 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 to try to implement things and see how they how they feel. Um so I I like kind of interacting at that that level. But yeah, I it's I think it would really slow the process down if I had to um kind of give people a stability guarantee as well as pulling in their contributions. The ability to like just change the controls.

Bryce 11:13

Sorry, the dog was tearing at something she was not supposed to be tearing at. None, come here. Continue talking.

Conor 11:24

Welcome to ADSP the podcast. So we've gone downhill since the beginning. You know, Bryce likes to have his dinner while we record. You know, the dog is like uh basically a third co-host at this point.

Sean Baxter 11:36

Uh okay, the dog is on Bryce's lap now, like a small child.

Bryce 11:42

Because the dog the dog was trying to eat her her dog bed, which I've had to sew up holes in that dog bed three or four times. She really likes pulling stuff in that stuff.

Sean Baxter 11:56

So anyway, so the last the last statement about open source is that um since I don't have any source code users, I'm free to kind of refactor the code continuously, which I do. Um and you know, if you can't really have an open source project where the internals of it change so rapidly, it just breaks everyone's downstream project. So for me, right, at this point, it's it's important for me to stay nimble and uh speak to myself.

Bryce 12:21

But it is freely available, right? If you want to if you want if you want to use the binary, the binary, sure. Um and it and it's interesting, Connor and I last week talked about um uh another programming language. Yeah, the K-programming language, which is another language that was that is developed by a single visionary person. Um it's not open source, and uh it's just uh released in uh uh you know a binary form. And I think there's there's sort of many similarities to that evolution story. Um although interestingly, with the K-language, there's different versions of the K or different evol uh not versions, but evolutions of the K language. And um uh when when the 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 can it it's completely from scratch.

Sean Baxter 13:15

Well, that's a 30-year-old project. I don't think I want to go for that long.

Bryce 13:18

Yeah, yeah. Um and then my my the f the final the final uh uh question or topic. Um you use LLBM as the backend in in Circle, correct?

Sean Baxter 13:30

Yeah, I have some others as well, but primarily LLVM.

Bryce 13:32

So maybe can you maybe explain a little bit about how LBM is used in Circle? Because I think a lot of people maybe hear about Circle and they're like, oh, like it's gotta just be an extension of Clang or something like that, um, which it's not. Right, it's not. Yeah, so it's not based on Clang at all.

Sean Baxter 13:47

It's a completely there's no Clay dependency. It's unrelated to Clang. Uh LLVM is an intermediate representation. It's it's like an abstract version of assembly, and it targets a um a virtual machine, the low-level virtual machine, and there's instructions like you would find in an Intel or ARM assembly guide, uh, but these are for this this abstract machine, and then you emit code for this IR and LLVM lowers it. Um so it's it's really a portable assembler. Uh it leaves up to you like the um responsibilities for binary interface and kind of understanding the requirements of the operating system. It's it's very low level. But it's like I just yeah, I target the LLVM IR, but I don't have any claim dependency.

Bryce 14:34

Gotcha.

Conor 14:35

Alright. Now should we stick uh because we got over like what 10 minutes into this recording? Because if we want, we can chat about, or should we switch to the next topic? Now there's nothing more we want to say about circle.

Bryce 14:46

You said if we want we can chat about, and then there's a dot dot dot there. If we want, we can chat about what?

Conor 14:52

Oh, like continue to turk talk about circle for a little bit, because we're gonna slice and dice this up.

Sean Baxter 14:57

If we want to talk about carbon uh Nah, 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?

Conor 15:09

What do the listeners want? Oh, they're hearing this. Uh-uh.

Bryce 15:13

The listener.

Conor 15:14

The listener. Um well, I I think I'm curious, you know, and maybe the listener's curious, what is the biggest difference? You sort of you mentioned the compiles 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, etc., you know, what's the 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 can what makes up the delta that would cause people to make that decision?

Sean Baxter 15:47

Well, I'm I'm really bleeding edge. So I 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 um universal template parameters that missed the 23 window, but it's been in circle for like a year and a half already. Um I I 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 um 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 um kind of truism, which I think is not right, which is that it, you know, what did they say, the at the center of C there's a simpler language waiting to get out, something like that. Yeah. And I don't uh uh or a smaller language, I don't think a small language is a simpler uh or a more streamlined developer experience. And I think that getting first-class language features, um, which Circle as a as a code base is really uh tuned to deliver, um, I think that's super valuable. And and the idea that we're gonna pare down a complex a complex language that has 40 years of history uh or 50 years of history, and somehow that makes it more responsive to user needs. I don't I don't really believe that. So, yeah, I I think really it's about um trying to anticipate uh where the kind of work that users want. God is whispering.

Bryce 17:21

I'm sorry, her mom is in is uh is in Virginia today. She's and she she just doesn't behave as well for me. I'm the fun parent, not the disciplinarian.

Sean Baxter 17:33

Uh yeah, so I I'm just I'm I'm I'm looking for I I guess I'm still looking for that killer feature. I think I might have found it recently. But uh I'm just exploring the language design.

Bryce 17:47

What's the killer feature that the language tuples are?

Sean Baxter 17:50

No, language tuples are are I mean that's nice, but we we can get it. Okay, alright, alright.

Bryce 17:56

Well, okay, so so so another question. Um is Circle the uh most uh uh like up to date with the standard C compiler these days. Like if you want to try out the latest C236 features.

Sean Baxter 18:16

It's hard to say. Um a lot of it is kind of gated by what's in the standard library. I mean, because what else is using these features? Um it's possible, I don't know. Uh it's like I'm not even sure what's going in 23, honestly. I'm not even sure what's going in 23. I I try to keep it very up to date, but um it's really like it it matters if there's a usage of a feature in a test case in like the libclus plus test suite. Yeah. So uh yeah, as far as as far as like standardized features.

Bryce 18:48

Okay, so so so I want to go back to you said you found the killer feature.

Sean Baxter 18:53

What is it? Well, I think we maybe want to pivot to successor language. Okay, all right, all right. Kind of what I'm thinking about.

Bryce 18:59

So uh we we we will get we will get to the topic that Connor wanted me to to uh discuss with him last week. What do you think of CPP front?

Conor 19:10

Also, wait, should we before we get the answer, let's let's just enumerate off the top. Um, 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. Uh CPP front, aka C2, aka whatever else you want to call it, um, got announced in the closing keynote at CPPCon.

Bryce 19:49

Maybe, maybe not a great uh naming strategy to give the name to I mean it's I've seen it referred to as both CPP2 and CPP front.

Conor 19:59

Uh you mentioned jacked, which is the language that exists within Andreas Kling's Serenity OS. Val is a language out of Adobe by um Dave Abrahams and friends, um, formerly who worked on Swift. Is there any other languages? Or even Sean, if you want to, if you know, if because apparently you've been you've been watching from the right.

Sean Baxter 20:24

Um so I mean a carbon is obviously the the biggest um most ambitious attempt, and it has it's the one with the real resources behind it. Yeah. Um 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 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.

Bryce 21:03

I actually think I I so I've seen the the um this uh talking point come up a few times in various talks about carbon. And um I think that I think that it's perhaps phrased that way because it the 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. Um but um I I I suspect that all the 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 uh opportunity, but I think they also just want to build a good language that that maybe. At some point in the future, that language would be a language that would be good enough to use for new projects.

Sean Baxter 22:08

No, I'm asking though, why not write it in Rust?

Bryce 22:11

Yeah, but I think because they're they're C folks, probably because they're building on top of like the LLBM library. On top of LLBM. Oh, you mean like the interpreter? Yeah. Yeah, I don't know. That's that that that you you make a good point. You make a good point. But you put a bunch of C people in a room, they're gonna probably try to use C.

Sean Baxter 22:33

But they're 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 what is about C and C. I think a lot of the point.

Conor 22:44

Um I do I do know, I and I think it's okay to mention this, that um at at one point they were considering writing the interpreter in Swift.

Bryce 22:52

They were considering writing the interpreter in Swift? I I I should know this because the Connor and I have been uh uh uh read in on the work for for a while. But we've we um we just we're observers really.

Conor 23:08

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 gonna be easier to write it in C for now. If we want in the future do something else, maybe we consider that. But I I I think they actually did, you know, that doesn't answer why not Rust if Rust is better. But um they were they did consider using a different language at one point.

Sean Baxter 23:47

Um Yeah, fair enough. Yeah, yeah. So um the tenets of carbon I I mean they're kind of tough to swallow. So the first of all, uh there's no function overloading by design. And I think C is really C width overloading. That's kind of the core of the language. There's no exception handling. Uh a lot of people don't like exception handling, but on the other hand, if your C code is potentially throwing, uh you're gonna have to have a uh another language that understands exceptions to be able to support that.

Bryce 24:19

That that part I I don't fully like I I I think that that perhaps that part of a carbon experiment has not been.

Sean Baxter 24:29

Well it gets better. It gets better. 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. Um really rely on that on that feature. And it's got no like runtime penalty, it's just a way to organize uh classes. Uh there's um right now there's like no sense of you know raw pointers or real pointers. Uh I think that's gonna have to change because when you interact with system code that's gonna give you back pointers, uh you're gonna have to like deal with pointer arithmetic and and and all of that. Um there's a lot of surface area in header files that have pointers for you know good reasons. Um 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 like a factory function, a static member function, and that's gonna have to return like a pair or you know, a um like a variant with their error code and the construct or the constructed object. So in that sense, it's like Rust, but there is no um there are no constructors right now. So there's no sub-object initializers, at least in the conventional sense. So the question is like how how is it gonna seamlessly interoperate with C.

Bryce 25:51

And I mean that that that is the big, you know, open question with carbon. You know, the the th the thing that the the where 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.

Sean Baxter 26:20

Um uh well I I don't know about that. I think um I think carbon, my reading of carbon is that it's the Google's C style guide turned into a language. And the Google style guide says no exceptions, um, 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 um experience um 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.

Bryce 26:59

Well, I don't I I I I'll push back on that. I think that the folks buying carbon, um, I think they recognize that as a project that was started by people like Google that started originally as an internal Google project, they they understand how important it is for something like carbon to be successful for it to not just solely be a Google thing.

Sean Baxter 27:20

Why?

Bryce 27:20

And because I think it is uh 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, um it becomes very tailored to that organization's needs and uses, and that that puts like a cap on on how far it can grow.

Sean Baxter 27:43

But we're talking about Google. I mean, it's a country unto itself.

Bryce 27:45

Yeah, yeah, but but but like they specifically don't want it to be a Google-only project. And they don't want it to be perceived as a Google-only project. And it's and it's not that it is admittedly true that many of the core collaborators are folks at Google, but they've they've gone to great lengths to build a wider uh community. Um and you know, I'll I'll I'll say this. There are the the the thing that I have the the greatest, I see the greatest potential in in carbon um is uh its governance model and the people behind it and their goals. Um so I can I agree with the goals that uh uh that the carbon language has. Um and I think that more important than where a particular programming language is today, to me, um, is how that programming language is uh managed and how it evolves. And I have um uh a great deal of confidence in the evolution process that they've set up and in its ability to um uh to address these problems over time. Like I think if carbon is successful, the what carbon will look like in you know three to four to five years when it starts to become successful will be very different from the shape that it is today.

Sean Baxter 29:10

Um I'm just going on what the current design docs say.

Bryce 29:15

Um but but I 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 um to something that works for you know for the the audience that they have in mind and achieves this those goals that they have in mind.

Sean Baxter 29:36

Okay, so on on the flip side, I mean I enumerated all these things that carbon removes that C users expect to have, like function overloads.

Bryce 29:45

Yeah.

Sean Baxter 29:46

Uh but they I mean they 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 um, instead of uh function overloading, there are there's like concept uh-based overloading, or what they call like Rust traits, or in uh Swifter protocols, and in C prior to 2011, they were concepts. Um they're putting a lot of uh investment in these interfaces or these these traits. Uh the other thing is uh some types, they have a choice type, which is just like the Rust Enum, and they have a first-class um tuple. And uh so when when carbon was announced, you know, I I thought like, you know, what is 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 uh like a sum type, a uh you know, a language little variant. That's like it's really easy, it's just another data type. It's just a you know a tagged union with some compiler-generated uh constructors and assignment operators. So I implemented that um 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 uh a choice type called result and has an OK field and an error field, um you can use the uh comma operator and at runtime it'll examine the um active element of the uh choice type and it'll return it'll either yield the okay element or it'll return the error. And this is a way to like propagate errors without exceptions. And and this is what you need with when you're like using these factory functions, since you don't have constructors, uh a factory function would return a result of the that type, comma, whatever the error code is, and then you would be able to use the comma operator to chain the propagation and um without a whole bunch of typing, have a kind of static exception handling. Um there's syntax for uh first-class language tuples, so it's just like comma separated list of types or comma-separated list of uh expressions, and then finally there's concepts or what what uh Carbon is calling interfaces, so as 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 uh concept wording. It's like 100 pages of wording, Doug Gregor, mostly Doug Gregor, um, and there was like there's the Indiana School and there's the um 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 um uh 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 C20, and then they were without concepts rather, and then concepts we got were concepts light, which are basically just uh porcelain around porcelain around enable if. So it's it's really kind of gutted the feature. But that concept um feature from you know 2006 is exactly what carbon is staking really its entire um core on, which is how do we do how do we do overloading and how do we do generics? And for them, they they said we want to have these C OX concepts. They used 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. Uh but I I think collectively I I have 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 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 like really like Dave Abrahams at CPP now, he was still agitated and angry about the removal of concepts back in 2009.

Bryce 33:54

This led to a large schism in the C leadership. Um arguably, I think if if not for that schism, you know, it's possible that uh you know the folks like Doug Grego and Dave Abrahams who went off to create Swift would have still been working on Cat's time.

Sean Baxter 34:15

I think this was a a major defeat as far as like losing um you know senior leadership. Yeah. Um yeah, and I I think for some of the 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. I think a lot of the um the voters they go to the mat about what if they like a feature or not. They think it's a good feature. And 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. Um, but I know that a lot of other people really care about him. I mean they really care about him. And and you know, I'll 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 should give them the benefit of the doubt and say if they're really interested in these features, we should put that in the 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 um you know more of a benefit of the doubt when it comes to uh adopting features. The language won't evolve otherwise.

Conor 35:48

In doing your historical deep dive, was it documented why they ended up um getting rid of them? Like obviously there was folks on the committee that obviously weren't a fan of it. Like, was there what was the justification?

Bryce 36:01

Oh but buddy, you're you're gonna have to uh that that's a whole nother episode where we get we get some people from that time period on to talk about.

Sean Baxter 36:14

Well, I mean I've 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's doesn't answer all my questions, and there's really nobody to go and ask anymore because we're stuck, we're talking about like language that's 15 years old. Um I I think there was an issue, a disagreement between like Bjarn's camp, Bjarnus camp that wanted uh implicit concept maps, so that uh 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. Um 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 like getting consensus on what the default should be, um the rest of the C committee members just decided to remove the feature. These are 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. Um I mean, I'm sure there's like a lot of uh interpersonal conflicts.

Bryce 37:21

No, I I think there were I think there were, but um it it was a combination of a variety of technical disagreements, and then those led to a variety of interpersonal arguments, and um uh I I think it reached a point where both camps became very entrenched, and um there wasn't really a uh a compromise to be found. Um I I I tend to not particularly like the design of the concepts that we got. Um I think that the uh the OX concepts design was much more natural and much more how I would imagine. Like when I when I when I write up in like a comments like what a concept should look like, it's much um uh you know, like I I define sort of like the you know uh uh the the archetype of of what it would look like. And that's much more what the C O X concepts look like. Whereas with the concepts that we have, you have to like write out these like examples of like how it'll be used. And I just find that supremely weird.

Sean Baxter 38:42

Well the concepts we have now uh don't do type checking definition. That's the big difference. Like um Rust traits and what they're trying to put into carbon, which they're calling interface, um, and and the Swift protocols, which is actually separate compilation, uh, and and there's like a runtime penalty for using the generics in Swift. But but but the general form is the same. That's that type checking is done uh at definition. So you write your um function generic, and uh each of the uh template parameters, or 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 uh that are parts of the interfaces for each of the 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. Uh in C20 concepts, the concepts are just uh 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.

Bryce 39:52

And and 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 believed that um that it would become impractical or um computationally impractical or something to that effect, um, or the c or it would be too complex. Um but then we ended up with this concepts light, and without, and you should you certainly can't do tech training in that model. Um, but without that, what's really the value of concepts? Like it 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 uh the diagnostic experience in the ways that we thought it would. Um and it yeah, like I I don't really see what the tangible benefits are other than it's a cleaner way to do enable if.

Sean Baxter 40:59

I I don't think we have to worry about C20 concepts because we have evidence coming from these successor languages. Swift has the protocols, Rust has the traits, uh, and you know, now there's like a decade of uh usage experience where the customers are more or less satisfied with that, with that um 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 I have um archetype establishment, which is when you mark up your function template with all these interfaces, it's the conjunction of these interfaces um indicating the the um capabilities of the types. Like 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, um in the current C scheme, you can't use any of those member functions because those member functions are only known once that um that class templates specialize with real types, which is during instantiation. Because you don't know if it's gonna hit a partial template specialization, if it's gonna hit an explicit like explicit specialization. So I've been going through and like creating new kinds of fundamental data types. So I have uh class generics and choice generics. So if you have um you know template with the template parameter list class foo, that's a current, that's the regular class template. But if you have generic with the template argument list, class foo, now foo is a gen uh is a class generic, and that will actually 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 I think the the problem is that, and maybe this is 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 like convenient. But but I think a lot of the decisions for generics and Rust and Swift, and I'm sure carbon, when it kind of shakes out, is gonna s um to limit partial specialization and explicit specialization to allow you to fully type check the data members of a of a class that you're using inside a generic function. So I've got I've just got like 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 like concern about breaking compatibility. Because it's written, it's all embedded in in you know existing C compiler.

Bryce 43:39

And what's your motivation for doing that?

Sean Baxter 43:42

My mo my motivation? Well, I I'm always looking for features that are gonna bring you users, yeah. Yeah, it's gonna be the hit feature.

Bryce 43:49

And I think that But is your is your point also that we don't need a successor language because we can make C better?

Sean Baxter 43:58

Um 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 held this successor languages. Because if if these successor languages work really well, then they can speak for themselves. I'm I'm just speaking for my evolution of C. And I think that um you know, C gets a lot of flack, but I think we can still evolve it in any direction we want. If we wanted to put Val style value semantics in it, I think we could do that. I think we could evolve it in really almost any direction and and still retain core uh compatibility with all the code out there.

Bryce 44:37

Yeah, I I I tend to agree with you. Um I think most of the C ⁇ committee and most other implementers don't. What what why do you think why do you think so people s so few people see the potential for evolving C?

Sean Baxter 45:02

Well, they don't want to have to do 20 years of uh proposal revisions. I mean, for some of these features, there would be they would take forever to get through the committee.

Bryce 45:11

And I think and it's easier for for one person or a small person.

Sean Baxter 45:15

Well, no, it would just 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 superset of C. Yeah. It could have had a new syntax, they could have, even if they wanted, made a context-free, a new context-free grammar that has not even all the features, but still plugs into the existing compiler. Yeah. Right? Um now, I 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 gonna work all the way through. And you can make your incremental changes and you can evolve it in any direction. And I think um, you know, that's that's what I'm doing. And and having a really nimble C compiler source base, you know, allows me to do that. And I think that's really the value of it.

Bryce 46:06

But you also you don't have a committee of 300 people that you have to get to sign off in some.

Sean Baxter 46:12

The claim maintainers don't have to do that either. They could have just said, we're gonna fork carbon, and carbon's gonna be basically claying with other features. They didn't do that.

Bryce 46:20

Why don't they?

Sean Baxter 46:21

Well, I don't know. I mean they they have a different different strategy and a different I mean, they think differently of C ⁇ than I think of it.

Bryce 46:27

Right, because I think they would argue that's not C ⁇ , that's C ⁇ with exemptions. Well, okay. What's the difference, though? At what point does the circle dialect of C ⁇ become its own language?

Sean Baxter 46:39

This is I don't think this is a this is just a vocabulary distinction. I don't think it has any um it doesn't affect anything. If you're what matters is if you're a company and you've got billions of dollars of value in C ⁇ source spaces, um you want to keep compiling that. You want to make sure that every year you get the new version out of your of your the new build out. And it'd be great if the compiler improves with your own software. Yeah. And and and we can do that. Like we can we can evolve C ⁇ much more quickly and and actually give users the features they want uh without having to break anything. You know? Or if you do break, it could be a tiny, like a small break. I have I've I've gotten a lot more bold about my extensions recently. I've I've realized I have I've just pragma with pound pragma feature and then the feature name. So I have ones like pound pragma feature generics, pound pragma feature, tuple, um, a couple others. And and what they do is they draw in new tokens, but only for the file. Yeah. 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'm not- I know I'm not gonna break anything because the syntax is gating, um, or that that that pragma is gating which source uh lines are exposed to the new features. And you know, you just just try it out. I keep turning it over and over. And so I've been turning over uh these function generics, the class generics, tuples, choice types, and I'm 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 Carbon wants to offer. Yeah. Without any question about, well, it's not going to support exceptions, it's not going to support, you know, function overloading. Uh yeah, for me, this is this is the way to move forward. And I'm I'm very I'm actually happy with the successor language of languages because it's mean there's other people thinking about what features are important, and then I can go and you know implement those in my own system.

Bryce 48:51

Yeah, so I I do agree with you. I do suspect that in practice in the field, some of that some of the ways in which we would evolve will become constrained by actual real world impacts of um of making breaking changes. Um but I I think that that the C evolution process has essentially become uh paralyzed by this this this fear of what will happen if we uh uh make a breaking change.

Sean Baxter 49:39

And why is everyone talking why why is everyone so fixated on breaking changes?

Bryce 49:44

That's a good question.

Sean Baxter 49:44

I mean, none of this has like interface generics, right? We can we can we can put these in, and that doesn't break any code. Um types don't break any people want pattern methods. Yeah, so what? I've I've like I I guess that I'm getting those. How pragma feature interface? Do it your source file. Your new source file, put that in, right? You don't have to you don't have to worry about all your system dependencies because they're a successful approach in other languages, right?

Bryce 50:09

Doesn't JavaScript do this? Don't they have uh uh you're you're the program language person, Kyle. I expect you know that.

Conor 50:19

I don't know anything about JavaScript other than they got like 17 different ways to compare things and so what everyone whines about is triple equals, blah blah blah.

Bryce 50:28

Um I believe JavaScript has a new strict thing that if you do it it gives you more modern.

Sean Baxter 50:35

I just think there's been too much made about ABI breakage.

Bryce 50:38

No, I I I don't I don't mean like ABI breakage, I just mean like, you know, evolved like yes, that that that's a problem, but I think in a lot of the the cases and examples that you have in mind, it's not a question of ABI breakage, it's you're interested in new syntax, new Yeah, so but what's the problem?

Sean Baxter 50:52

It doesn't interfere with the old syntax.

Bryce 50:54

Yeah, I I I 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 I think at the end of the day, the the problem is just that the C evolution process moves so slowly.

Sean Baxter 51:08

I think epics, uh 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 some people what is best I don't really believe in codifying like best use or best, you know, best practice.

Bryce 51:23

There's another reason why I think you'll get resistance in the committee. I just remembered this. Um there's this fear of creating dialects. There's this fear that if you have like these modes that you opt into, then you create then C becomes charted into multiple different dialects of C. I I personally think that this is not uh um not a reasonable argument because we already have dialects. Well, yes, we have CUDA, but also you know, between C 11, 14, 17, 20, like in the wild, like people programming these different, you know, uh uh time snapshot uh 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 I don't understand the 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.

Sean Baxter 52:45

Again, I think this is a I'm not I'm trying not to again I when I see can of worms I don't go and open it. Yeah and I'm I I I disagree.

Bryce 52:55

I was I wasn't gonna take a point about this earlier, but we've got to go back to that. Dude, you built your own C compiler, that's like by definition opening up a can of worms.

Sean Baxter 53:05

Well, no, I mean it's something you can make consistent progress at if you just push at it. And and this thing about, well, this existential crisis about breaking compatibility with old code or breaking ABI, I I don't, I'm just I'm not personally that interested in in that fight. Like I don't I I could go either way, I don't care. If somebody wants to spin a new libclus that has like different data layouts or types in the same namespace, like, alright, I mean it's just something to point the compiler at. For me, it doesn't really matter. And I, you know, I I think we should let the vendors do what the vendors are gonna do. And if you're on a a managed Linux system, like if you're on like 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 ABI if you're gonna 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. Um, I 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 old code.

Bryce 54:18

Right. Uh I agree, but it but the problem is that it it requires us to take bold steps to do that. Um or that and it it requires the committee to take steps that the committee thinks as uh thinks it is bold. Um I don't know. The reality is that it takes it takes ten years for any new idea to get into the standard. Right. And so it would take ten years for us to get pragma feature or epic.

Sean Baxter 54:51

Well I'm but I mean by saying pragma, I'm indicating I don't really care about standardization. Like I've chosen a vendor extension.

Bryce 54:58

My point my point is just that like if like like if if we just assume that that that there's really my point is that even if all three of us here agree um uh that this is a thing that's like research or there's like there's there's no real reason not to do it. Um and even if most C Listics programmers would agree that we should like have something like some some mechanism like Epex or or program a feature that would allow us to model language better. Even if everybody in the committee agreed upon that, and I'm I'm pretty sure that we've taken calls to that effect, it would still take ten years for us to hammer out the details on the code.

Sean Baxter 55:43

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, like what's more what's more important is it is it um adhering to the ISO standard, or is it like being able to compile their software and having like confidence that they'll be able to compile it next year as well? And I think we've conflated the two. Like uh companies have gotten they're they're they're confident that C ⁇ is a long-term thing because it has this like 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 the interoperability story there is like very questionable. So if if the question becomes, well, we either jump to carbon, whatever that may be in the future, which has really there's no guarantee it's gonna continue to compile our existing code, or we we just suffer with C20 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 the the less risky one, which you're right, it's not gonna sail through ISO standardization, is to take the ISO standard, yeah, honor it, like, yeah, I'm 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 sum type.

Bryce 57:18

And you know that, and I think it it it sounds like you are essentially calling for revolution. No, I'm not calling what is what is with this?

Sean Baxter 57:26

Connor, do you have to do this with Bryce every time?

Bryce 57:29

No, no, no, no.

Sean Baxter 57:29

I mean, I exactly I take uh I take the most conciliatory tone possible, and he's saying I thought Pierre over here.

Bryce 57:38

But if you if you unpack what you're saying, what you're saying is that we should just take ISO C as it is, and then we should, and then compiler vendors should build the features that users want. That's not revolution.

Sean Baxter 57:51

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

Bryce 58:12

But like it's But but but what people want is they they want to be able to. People are afraid of vendor extensions. They want those, that they want to be able to use, to take their code and use it with any C compiler.

Sean Baxter 58:24

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 there's zero hard compilers. Right? So every other language has just one.

Bryce 58:34

Are you advocating an even more interesting position of that we should just have one C compiler?

Sean Baxter 58:41

No, I unbelievable.

Bryce 58:44

No, no, no. No, but but why not? You have like such isobrain, it's it's No, but but but why shouldn't we have one C compiler?

Sean Baxter 58:53

Look, I because if that was the case, I would never have been able to write mine. If there was some law where it's like if I'm not saying there should be some law. If there's some some enforcement mechanism where the SWAT comes in and like Well, if we're gonna have one C compiler, it should be circle. Oh well, yeah, great, great. No, I think uh it's important that everyone look, I'm not against the successor languages. Yeah. I think uh, you know, they say carbon's an experiment, like good. I think the scientific method of trying things out and trying to learn from that is good. Um I I want to do what they're doing, but from a different direction. For me, compatibility is really important.

Bryce 59:31

Yeah.

Sean Baxter 59:31

You know, for me, I'm extending ISO C. I'm I'm I have the same features that Carbon has in mind, and I'm just putting them into the C compiler.

Bryce 59:41

Okay, but what if what if another compiler wanted to like 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 it works.

Sean Baxter 59:57

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. I mean, I 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 is?

Bryce 1:00:13

Um that's like not that hasn't been the case really in twenty-something. Um I I think the committee wants to 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 um there's one, there's just there's just too many people. There's there's there's uh there's too many perspectives. I I don't think that uh a I don't think that you can have your core decision-making body be like 300 different people. Um I think like there should be like eight people at most that like make final decisions on things. Um there's there's there's it's not that there's too many voices, carrying 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 gotta 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 to 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 everybody's constraints.

Sean Baxter 1:01:54

Um yeah, I think that's how it plays out. That's that's probably an acrodynamic. 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 I think that we should have a more liberal attitude, which is 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 Astrid. Like you said you're you're angry that a lot of people had objections to it.

Bryce 1:02:28

I I felt that it was such a good the the issue that I had is that I think people fail to appreciate um the vision that you have and uh how much you've driven forward the the world of C compilers. Just just if for no other reason than by demonstrating to people that it's not some like big scary thing that like, you know, you there's only three people in the world and you need like these huge teams to do. Like you're you're just one guy who went off and built a C ⁇ compiler, and when you wanna, you know, when they're 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. Um and it it not everybody, I think I I certainly I don't agree with every aspect of your vision of the specifics of what you have in mind. Um, 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. So I'm like, but you're missing the point. The point is that we have so many options that we can we can ex- we can move faster, we can explore all of these things, we can make the language better. Um people just wanted to focus on that.

Sean Baxter 1:04:14

Yeah, I think I said something like, um, I'm not trying to convince you of any individual future. I'm just trying to convince you that incremental change will make the language better and more.

Bryce 1:04:22

Right. And what made me sad was that people didn't focus on that, people focused on that.

Sean Baxter 1:04:26

Well, yeah, I think it's just like take a beat. You know, like I I delivered like 90 minutes of like rapid fire. There's like oh like here's like 20 new features, right? And and just like sleep on it at least. And and try to look at it from a different angle. Because I think there's a lot of preconception about what meta programming should look like. And my stuff didn't look like that. It might have looked more like JavaScript or something else. I mean I I didn't really have any individual idiom. I was just trying to do things that would cut would cut cut through the nonsense we deal with on a daily basis if you're writing like standard library code. Um and in that sense it was like very non-ideological. I was just trying to get to you know, f complete the problem, you know, finish the problem. And I think people just need to like adjust their brains a little bit to take to s to s to sit back and say, does this help me solve my problem, as opposed to 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.

Bryce 1:05:37

Uh and I you know, it going back to the epics, I I think the epics thing is a perfect example of that. The one of the biggest objections to an endic ethics has been this ideology that we can't have dialects or subsets of C, that it needs to be all one coherent vision of a language. And I I'm sure. that there's a motivation for that but um the the sort of the absolutism of like that keeping us from doing impossibly the one thing that could really unlock our future is I think very uh very troubling and and it's the 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 of variants or dialects um and so we shouldn't we shouldn't do or encourage that. And there's a lot of things like that where where we we the committee is presented with some option and that option would fix a real problem that we have. And but we don't do that thing because of some theoretical problem that that might happen if we do that. And it's like the house is on fire um but we don't want to put up the fire because you know that could create some other problem.

Sean Baxter 1:07:10

Well maybe we should focus on the problems that we have there are I 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 if you can make them five percent, ten percent 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.

Bryce 1:07:44

But one of the sad things and I think y you will be intimately familiar with this big tech companies so drastically undervalue developer productivity. And like this is one of the reasons why there are so few like compiler front end engineers relative to you know compiler back end engineers. 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 of big tech companies perspective is like oh well you know it's painful to write the code like that's okay like we got good developers like they'll they'll be able to do it. And it's like it's exactly what you said you know if you make if you make all your programs 5% more efficient that is going to save you so much and uh and it and it it is sad that it is sad the degree to which I think technologies like compilers are undervalued. 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 and there's only really one front end company left that's CPG. And there's just not the money in the developer tool space that there is in other um in other sectors. You know if I if I go to a a programming language conference like C or like C this was now or uh CPCon back when I went to CPDCon, um 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 where they sell hardware and it's like there's so much fun in there. The whole exhibition hall is 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 get to programmers as much as we should yeah okay but you but you never answered the question what do you think of CPP front?

Conor 1:10:04

Yeah well so yeah I was gonna say we've been talking about um carbon and circle and C. 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 because I'm sure that some of our listeners have no idea what we're talking about because they have not seen that keynote yet.

Bryce 1:10:27

I did not watch the keynote wait wait kind of did you watch the keynote?

Sean Baxter 1:10:31

I did yes I uh I I was like the I participated in Herb's keynote from the previous year where he showed a pattern matching proposal which I implemented in Circle and after I sent him that code he sent me the CPP2 doc which is not public and that's like 120 pages.

Conor 1:10:49

So I read the doc so I have more information than wait so when 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 subscribed I thought that this mostly was a reaction.

Bryce 1:11:10

I don't know 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 heard of it and Herb should have he should have done this announcement like a couple years ago. But this is I I think um I think there's it there's always like this this this challenge when you got this new project of like when is it ready to show? Well it's not ready to show but it's gonna show it still yeah exactly and I I think that that's really hard for some people. That's fine. Yeah.

Sean Baxter 1:11:41

But but I I think um you know carbon I think picked a good sort of time and one thing that carbon did was carbon didn't um you know go public you know like as soon as it was in uh conceived of but they had a pretty long period where they brought in more they brought in more and more things I think carbon was too early announced yeah it doesn't I mean it doesn't it didn't even have like not equal operator it didn't have less than didn't have integers other than 32 bit didn't have floats it didn't it it it's not like a you can't compile anything there's no compiler I think they should have they should have got code generation but I I agree that like CPP2 I think would be f far more effective and more likely to to gain traction as an idea if it had been um announced earlier I think data with things like metaclasses etc yeah because I I looked at the repository and it started in mid-2021 or late 2021 and and almost all the code contributions happen since July so just like three months ago. So uh when I was talking to Herb he had just started like this was last summer he had just started that repository. And like you said it's it's a I guess he's calling it a transpiler but it doesn't like it it's not a compiler so uh it's a one-way, it's a one-directional thing which is not you can't actually make software that way right like if you're textually if you call a function you have to know what the return the result object type is of that function and there's no way to to determine that from from this architecture he has. So it's really just a way to show the syntax I think. The real value is in that document which I don't think he's made public still. No. Yeah so that is I guess this is kind of the same um I'm not gonna say criticism but I'm gonna say this is a different philosophy I have from carbon or from CVV2 which is we can dis we can disaggregate these features. Like Herb's feature major feature I think is the parameter passing. He has these uh directives like you know in, in out and they may compile to different things. They may emit an R value reference or it may emit um you know a deep copy or a pass by value if it's like a trivial type. Like you can disaggregate that and you 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 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 stdmap or something like that with these with these um new parameter directives. I I kind of wish that he had focused more on the um the the features to disaggregate the features of CPV2 and focus on them individually. And he has kind of like he does have a proposal for static exceptions and I think there's that yeah there is a metaclasses 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 Rodan you know like the whole gates of hell tableau but like people don't want the whole tableau. They just want the thinker.

Conor 1:15:00

So you know Herb just like give us the thinker and and the whole tableau is a little bit much to buy into if you care about and just just in case uh our listener is not um 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 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 cpp2 and then it'll generate a dotc file which then ends up getting getting compiled and there's a bunch of new fancy stuff the inout stuff that just got mentioned which if you've watched Herb's keynote I think from the previous year a couple years ago he talked about that potentially being something that could show up in C and um yeah 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 because I'm guessing clearly these people that work on Java get a lot of questions like how come we can't have language X, language feature X in in Java and so what Herb said at the beginning and 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 you know largest I guess maybe not by this year's numbers but you know it's it's sort of known as the for for however many years the premier North American um I guess it's only one of two now three. Anyways point is it's a big conference and uh the closing keynote is like asking the attendees of the conference like not to leave the language. And um I was just kind of shocked that like that that was being because like in and like I said like as soon as he said that it made me think of like this uh 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 dead 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 like 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 it made me even think is like is this like actually like some inflection point and is it be the beginning of the end we're seeing all these suggestions.

Bryce 1:18:41

I think it's definitely an inflection point. I think whether it's the beginning of the end is is a question up to um our user base and also the the leadership like what what what what do you think Sean like the what if you have could what do you think of of that and like also like if you had a crystal ball or you had to bet you know five ten years from now what do you what do you think the low level language space is gonna is everyone going to be writing in circle?

Conor 1:19:08

Is it going to be C 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