Chandler Carruth (Clip)

But we don't have one of these. This fits in these question marks. This doesn't exist. There's not a good language today that I can fit into those question marks that takes this exceptor language approach in order to be a compelling option for current C users. And a few of us thought, this is really too interesting to leave this way. This is something we need to explore. So we started building something that would fit into these. We're calling it the carbon language.

Conor

Welcome to ADSB the podcast, episode 88, recorded on July 25th, 2022. My name is Connor, and today with my co-host Bryce, we talk about the exciting new announcement in the programming language world, Carbon. Alright, so listener, we just started episode, I think it's 88. We're gonna be recording two episodes today. This might just be uh part one, part two. News to me. Because I'll be going to the West Coast, so we need to what's what is today?

Bryce

Why are you going to the West Coast?

Conor

My sister, uh middle sister, oh yes, my three sisters is flying back from Ireland for the first time in uh years.

Bryce

This is the sister that I've met. I've only met one of the three sisters. I know it's shocking to me too. Dear listener.

Conor

And so, yeah, my family is uh taking a weekend and whistler to whatever, just hang out. So bopping out there.

Bryce

Tell everybody, I say hello.

Conor

I will, I will. Um anyway, so we're recording these in advance, and we do apologize, or at least I apologize. I'm not sure if Bryce apologizes as well. We said that we were gonna record live from CPP North. So today is the 25th, and uh week ago.

Bryce

I'm gonna say it was my fault because I I decided to leave CPP North a little bit early because it was enough. It was enough.

Conor

Yeah, Bryce, you were originally supposed to fly out uh the Sunday or Saturday. Sunday, yeah, so we would have had a Thursday to Sunday to see ducks. Um was that really necessary?

Bryce

I just remembered you recording an episode. That was the squeaky ball. The dog loves things that squeak and loves balls. So I found the ball that squeaks. And uh now I've made a tactical mistake because for the next for the next 30 minutes, she's gonna think it's it's ball playtime and that that that that I'm gonna throw the ball for her.

Conor

This has got to be this is has to be agonizing for our listeners, because our listeners want us to talk about two things, one primarily, and and you're not staying focused, Bryce. And we got we got we got a hard stop here.

Bryce

What do our what do our what do our listeners want us to say?

Conor

Well, so we were in the midst of apologizing. Uh not only did we not record while Bryce was in Toronto, but we didn't record live. That probably wouldn't have ended up happening just because of how crazy it ended up being. We tried to get Chandler Carew from Google on the last day, and we could have made it work, but it just he had a flight and dinner plans, and we would have had to do it at lunch right before my talk. Anyways, so the two things that they probably want to hear about is CPP North, because we were both there and we've been talking about it for the last two or three months on and off, and of course, a large announcement that took place at CPP North in Chandler Gruth's keynote. What should we start with? Should we start with a CPP North recap or should we go straight to the big news and uh share thoughts?

Bryce

I um I think we start should start with um the big news because I think it'll be the most timely for it to be something that goes out this week.

Conor

Perfect. All right, so maybe part one of this episode 88 and 89. Part one will be carbon, and part two will be I don't know, afterthoughts, however it works out. Alright, so Bryce, you go ahead and recap the announcement that I'm sure I mean I'd be surprised if any of our listener actually I'm I mean there's some outside of the C community that listen that might not This news went pretty far and wide.

Bryce

Yeah, so um well so a group of uh of people, um, some of whom are from Google, some of whom are not from Google, um have gotten together and have decided to work on creating a successor language to C. And what what we mean by successor language is um a language that has as one of its core tenets interoperability with the language that it succeeds. So it's meant to be something that you can uh incrementally adopt in an existing C project. Um so a lot of people who have looked at it have said, well, this looks quite similar to Rust. Isn't Rust the successor to C ⁇ ? Um and it is true that Rust and C have a very similar um target audience and that they're both systems programming languages. Um and it is true that there is some degree of Rust and C interoperability. But the difference with this new language, carbon, is that for carbon, interoperability is one of the key goals and priorities. And it's not one of the key founding goals and priorities of Rust. You know, the key founding goal and priority of Rust was memory safety and um and also to be a more accessible systems programming language than C. Um, but this interoperability question was not um you know one of these key goals. And um I think there's there's many other interesting aspects to Cartman, but I think the the this is really the defining aspect um and the aspect that will uh either lead to its success or lack of success. Um there's I have a few people at NVIDIA that have created programming languages that I work with, um, one of whom is Andre.

Conor

What what language for those that aren't in the know did he create or help create?

Bryce

He he helped create the D programming language. Um and I don't recall if it's Andre or if it's one of my other colleagues who have created a programming language. Um, but I was told that for a new programming language to really succeed, it has to be 10x better than you know the existing programming languages on some dimension. Not like 10x better, like in every way. There's like there has to be some 10x better aspect to it. And I think that's absolutely true. If it's a language that you need to like switch to.

Conor

Yeah, that requires like an immediate reading.

Bryce

Yeah, yeah. Um now for a successor language like Carbon or like TypeScript or like Kotlin, because the cost to adopt is much lower because of the interoperability focus. I believe that the bar for success is lower, that you do not need to be, you know, 10x better. Um uh that maybe you can just be, you know, 2x better in a bunch of small ways, or that you can, you know, clean up a lot of historical mistakes, that you can just make a whole bunch of smaller improvements, um, or or that that that that add up to being you know a much better um uh language, even though you know, maybe no one of those small improvements would be sufficient to get somebody to buy into I'm gonna completely rewrite um all of my software in this language. Um and and that to me is really the interesting thing about carbon is that it promises an incremental path, um, an incremental adoption, and that it can be incrementally better, um, that it can still retain um a lot of the priorities that we have for C, um, like performance and portability, um uh without um being tied down uh by the uh the legacy um uh that C has to deal with. Um but this is actually this this is not the reason why I'm most excited about carbon. I think the the interoperability is why I think most people would be most excited about carbon. But I am in the uh the programming language evolution business. And so the thing that's most attractive to me about carbon is its model for evolution and its process. And I think that carbon has a drastically better process than C. And in fact, I would even go so far as to say that the carbon process is 10x better than the C evolution process. Um, and I also think that that's probably true for a language like Rust or a language like Swift, these modern languages that um, you know, largely use our modern collaborative tools like GitHub for you know decision making and change management, um, and that use better stakeholder models, um, where you know there's some some sort of core team, um, but anybody can make contributions, and the core team really just makes decisions among a set of options. Um I I think that the the uh the difference in having an open model built on modern collaborative tools versus the rather dated um ISO-based model that uh uh C has, that's really a game changer. And I think that means that carbon will be able to um involve and improve and adapt um uh much better than C will be able to in the coming decades.

Conor

So just to be clear, do you like because you mentioned the 10x thing in terms of process, do you think that's a reason why at the end of the day carbon will be successful, or you're just mentioning it as sort of like I I believe that the reason that carbon and Rust will be successful is because they have substantially better process.

Bryce

Because it does it doesn't matter if they're better languages than like today. It doesn't matter if they're the right tool today. Um if you think 10, 20, 30 years down the road, and if you think about all of the known ways in which languages will have to evolve, but also the unknown ways in which languages might have to evolve. Um I have far greater confidence in uh languages that have an agile modern evolution process. Um and that doesn't mean that those languages can't interact with ISO. Um there are plenty of ways in which, if there was ever a need for a language like Rust to have an ISO standard in which that could happen. Um ISO commonly uh uh forms these relationships with other standards development organizations and has these fast track processes for other organizations that develop standards to turn their standard into an ISO standard as well. Um you could also imagine that the uh you know standards for something like uh Rust or Carbon could be developed um outside of the ISO process and you know by by some separate foundation, and then the results could be um uh contributed to um uh ISO. Um so the these things are not mutually exclusive. I just think that using the ISO process to evolve a programming language is not uh not the correct decision um e today. It was certainly the correct decision um in the 90s for C ⁇ . It was definitely the correct decision for you know older languages like C and Fortran. Um and uh in like in particular, it was certainly much better to have um uh ISO C than ANC C, because ANSI C was developed solely by a US-based standards development organization, and so its mandate was really very US focused, and ISO does provide a slightly you know broader uh uh view. But I think at the end of the day, um, you know, given the the collaboration tools that we have today, given how um uh software communities operate today, it um it's just not the right stakeholder model. And um I do hope that uh we can perhaps fix that in the future for languages like C and Fortran.

Conor

All right, so I will play the role of an amalgamation of the top questions that I have, because I've spent quite a bit of time and I'll link all of this stuff. There's the keynote from CPP North is that Chandler gave and made this announcement and is already online, so I'll link that. But also the Hacker News Reddit um thread, a couple different articles, and so there's been and and in the comments of the keynote that's online now, there's been a ton of discussion, obviously. It's it I think the Hacker News post for a a brief time on the Tuesday that the announcement was made, it hit number one, and there's hundreds of comments on the Reddit threads. Um there's been lots and lots of questions. I think you already asked probably the number one or answered already the number one question, which is why not just use Russ? A lot of people comment that the syntax looks similar, but you already talked about the interop story and how that is sort of the the big delta between the two. Um and there's others, but I that's sort of the I think the response to that question. The probably the second most popular question that I observed or comment that I made was why not just make C better? Which was actually, I think, a question that uh the carbon team during the QA um got. And so I'll let you know.

Bryce

I'll give the answer for the carbon team that I don't think you would have gotten during the QA, which is the people involved with carbon spent a decade plus trying to make C better. Yeah. Didn't work out. And like it's it's not like they didn't try. It's not like somebody like Chandler did not spend a significant chunk of his career and and time and effort trying to make C better. Um and actually, if you look through the history of C, there have been many figures who have tried to improve C through the committee, and have then departed to make programming languages. Um Doug Greger, Dave Abrahams, two of the people behind Swift, they used to be deeply involved in C. And they are they're you know prolific um uh software engineers and programmers and programming language designers. Um so why and then they love C ⁇ , of course. So why did they are they no longer involved? You know, Dave Dave is getting back into the C ⁇ world these days, but not so much the committee, at least, not that I've seen yet. Um well I don't want to speak for for these folks, um, but you know, I think I think it's telling when we've had throughout the history of C ⁇ not one, not two, but three or four times when large, significant contributors have decided that that uh their efforts were not um that the that spending more time on ISO C was just not worth it, and that they decided that they were gonna go off and do something else. Um now this is a sort of a unique case because this is a group of people who um are not going off to build a programming language with a different um uh set of goals and priorities. Well, I mean I I guess you could argue that Carbon does have a different set of goals and priorities to the sort of implicit goals and priorities of the C committee. Um I don't know that we've really properly formally adopted a set of goals and priorities. Um but this is the first time that a group of people have gone off to create a successor language for C, not a different type of language. Like Swift is a different type of language. Um I would even argue that D is a different type of language. Um and uh Rust is a different type of language. Carbon explicitly aims to be a successor language to C. Um now I I and I want to um circle back to that uh question about why um uh carbon and not Rust. And yes, interoperability is a big piece of it. Um, but I also think that uh there's other differences in goals and that are significant. Um Rust has memory safety as you know one of its key goals. That is not one of the key goals of carbon. There's there's a hope that uh memory safety will be something that can be um added to uh uh carbon, um, but it's not one of the key goals and priorities. Um I think the the focus on it um performance in carbon is um a sort of unique goal among other uh you know contemporary programming languages to it, and it's also a goal that um I think is to some degree shared by C. Um, or at least I think most people involved in the C evolution and most C ⁇ users feel that performance is a priority of C. Um now the the um the problem is when performance comes into conflict with um stability and predictability. Um I think carbon will will not be afraid to make breaking changes when it needs to, um uh and uh to to weigh the cost of that breaking change and uh you know how tooling might help us uh uh adapt to that breaking change versus the the benefit in performance. I'm not saying that carbon is going to make you know drastic, huge breaking changes for you know a 2% performance gain. I'm saying that if there's some some reasonable breaking change that can lead to you know uh uh 2x, 3x performance in some way in carbon, that that's almost certainly something that I would suspect carbon will pursue. Um whereas in C when performance uh when you have to pick between performance and uh stability, you we pick stability um more often than not.

Conor

Yeah, and there was a I'm sure a lot of our listeners know this, but there was a big discussion at the last in-person committee meeting before the pandemic started in Prague, and Corrington has a really good blog, which includes his personal thoughts on it, but it was a big discussion about ABI and whether or not the committee should take a stance on whether they want to break it or don't break it.

Bryce

And and I I actually I think that that discussion um could have been more productive because a large part of the framing of the argument was about performance, that we should you know be willing to break the standard library ABI so that we can improve the performance of um of things like um uh unordered map and things like unique putter. Um and that's that's a true argument, but uh I do not think that is by far the most compelling argument. I think we should be willing to break ABI so that we can make C easier to use. Like forget forget performance for a minute here. We should be willing to break C ⁇ ABI so that we can fix our mistakes, so that we can get rid of you know weird, confusing semantics um uh that uh you know don't make sense to users. Um we should be willing to make breaking changes, not just ABI breaks, but breaking changes so that we can get rid of um sharp edges and corner cases. Of C. We should be willing to make breaking changes so that we can make C a safer language, so that we can remove pitfalls, so that we can make C a simpler language, so that we can make C a more teachable language. I think that if you made that argument, you would get far more of the committee on your side than if you made an argument solely about performance. Because this question of velocity and stability is not just one about performance. It's it's it it affects the very nature of the language and the uh the complexity and the usability of the language. And uh it is it it saddens me that we uh did did not have that conversation at at Prague. Now, on the other hand, I am that that one call that one discussion was a culmination of many years of discussions, and I think many of the points that I just raised um uh have been uh discussed over the years. But I think the unfortunate thing was that because they weren't brought up on that evening when we took the votes, um some people's minds were just framed around the the question of performance and and did not grasp or remember the um the full scope of what we sacrifice in the name of stability.

Conor

Yeah. Yeah, it one of the most well, I I'm not sure if it's the most attractive thing, but just like carbon is gonna look so much nicer because they're gonna get the defaults right. Whereas, I mean, you'll start off writing.

Bryce

But but carbon doesn't have to get the defaults right. If carbon gets the defaults wrong, they can fix it. Carbon can fix the defaults. Like the the C I suspect got most of the defaults right at the time that we decided upon those defaults.

Conor

I mean, but that's the thing, is a lot of the quote unquote defaults that like they're getting decided on if you're not making a decision on it, right? Like if you if you're not taking into account some no-discard attribute on a member function. At the time, no one was thinking of it. So like implicitly the default was that it's not no discard. And so in the future, when the design discussion comes up, it's like, oh yeah, this would be a nice thing, but because you didn't the default was already decided. Um, so like I agree that probably when thinking about um the defaults that were being thought about, they got them right. But unfortunately, like you can never predict all of the future behaviors that you're gonna or design decisions that you're gonna be making that unfortunately you implicitly when you when you design something and you don't take into account like every possible flavor of something, it's gonna you might get the default wrong. But the point being is that like you know, in C I start off writing a simple example of some function in a class, and then like by the end of it, if I turn clang tidy on, there's like literally no discard, constexper, no accept, con like there's so many things that it's like a Christmas tree that you're hanging like little ornaments on by the end of it. It's like if if it's a small function, it ends up looking so complicated when really it's just a bunch of defaults that unfortunately we didn't think about at the very beginning. And uh that is gonna be super nice and something that Carbon really has going for it. That like, and I I can imagine, because I've seen these examples at Google IO when they were introducing Kotlin, where you would take some Java code and it would obviously it's a cherry-picked example, but then they have this automatic converter that like takes all this boilerplate and then converts it into like three lines or or whatever, and you you know that there's gonna be some you know cherry-picked C example that has all of these, you know, ornaments, if you will, and then it converts it into some carbon code and it's gonna look so much cleaner.

Bryce

Oh yeah, definitely. And you know, this um this reminds me of something from Sean Parent's keynote, which uh uh bookended uh the conference, and his keynote was called The Tragedy of C. And I loved it because it was um it was a redux of my favorite Sean Parent talk ever, and I think one of the best conference talks I've ever seen. It was probably the best conference talk I've ever seen. Um perhaps Hana's the first time I saw Hanna give like a full-length talk, um, or the first time that I saw you give a talk, um uh compete there. Um, but it's definitely in one of the top three. And that was his 2012 um C Now keynote, um, where he talks about um performance and you know how you get performance out of chip and um uh talks about heterogeneous programming, which in 2012 is pretty radical, and then he shows these amazing amazing demos of I don't remember which Adobe product running on um an iPad with rendering this huge image, um, and uh just very prescient in his predictions of where we needed to be, you know, 10 years later. Um and um uh yeah, this his talk, I was very excited to see him give sort of a talk that called back to that talk. He he showed a lot of slides from that 2012 talk in his keynote. Um I think obviously from the title The Tragedy of C, Sean feels that we've perhaps not come as far as we we would have liked. Um I I think in some ways we have. Um, and perhaps perhaps those have not yet become visible to him. Maybe those are things that like you and you and I see because we're committee members and we see those features going out the door right now. Whereas um uh Sean, who's not as actively involved in in the committee um uh these days, uh, but as a you know a C user, he's out in the field. He's writing actual applications and these cool new tools that we're putting into the next standard and the standard after that, you know, they're not available to him yet. Um and I think that's often one that's one way in which we on the on the committee often lose a bit of perspective that we standardize a thing and we're all excited about it. Well, there's like even after we've put it in the standard and shipped the standard, there's still a pretty long tail for it to get out to users. But anyways, in Sean's keynote, he showed um he referenced um I think a talk by uh Alex Stepanov where he talked about um the the complexity of std pair and he showed you know how many lines of code were needed to implement std pair in C 98, and I think it was like 150. And Alex Stepanov 62. And Alex Stepanov was just distraught that something so simple would require 62 lines of code, and then in C11 it was what, how many lines of code?

Conor

I think I think that was the one that was like 150.

Bryce

Yeah, and then in C 17 it was how many?

Conor

Five five five hundred or something, it like it like exploded.

Bryce

Yeah. Exactly. Um and um and it's the same in uh uh uh in terms of the size of the um of the C plus plus standard text, which has gone up um from you know a few hundred pages to I think it's near three thousand maybe now.

Conor

No, I think it's just under two thousand, it's eighteen hundred something.

Bryce

Ah, okay.

Conor

Um Although maybe C23 is.

Bryce

Yeah, I think C23 is probably over 2,000, or it will be once we're done with it. We just this morning we had the last C plenary um uh of the C 23 design cycle, where we shipped out the C23 committee draft and we had 62 motions and we voted in a lot of stuff, and that was that was easily 200 pages of things, um, would be my guess.

Conor

MD Span got in, congratulations.

Bryce

Which is MD Span is the reason I joined the committee back in 2015. And that's this is this goes this is an excellent demonstration of the point of you know how long of a tail it is to get things standardized. I joined the committee in 2015 with the goal of getting MD Span into the standard. It is 2022 and it is now in, and it it will not be widely available until like 20 until 2026, probably. Um so it will have taken me 10 years to accomplish this one relatively simple thing.

Conor

Yep.

Bryce

Yeah.

Conor

Probably wouldn't have taken as long uh in a non ISO model.

Bryce

So um I do not think it would have taken as long in a non iso model.

Conor

Thanks for listening. We hope you enjoyed and have a great day.