Algorithms + Data Structures = Programs - Episode 88: The Carbon Programming Language

Episode Date: July 29, 2022

In this episode, Bryce and Conor talk about the new programming language Carbon.Link to Episode 88 on WebsiteTwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachShow NotesDate Recorded: 2022-07-25Date Released: 2022-07-29Carbon Language: An experimental successor to C++ - Chandler Carruth - CppNorth 2022Carbon GithubD Programming LanguageCarbon on Hacker NewsCarbon Reddit ThreadThe Day The Standard Library Died by cor3ntinC++17 [[nosidcard]]C++11 constexprC++11 noexceptC++ const2022 Keynote - Sean Parent - CppNorth 22Sean Parent: “Now What? A vignette in three parts” - C++Now 2012CppCon 2018: Hana Dusíková “Compile Time Regular Expressions”STL and Its Design PrinciplesC++23 std::mdspanCppNorth Conference

But we don't have one of these that 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 successor language approach in order to be a compelling option for current SQLs Plus 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. 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. All right, so listener, we just started episode, I think it's 88. We're going to be recording

two episodes today. This might just be a part one, part two. News to me. Because I'll be going to the West Coast, so we need to, what is today? Why are you going to the West Coast? Going to the West Coast. My sister, sister oh yeah my three sisters is flying back from ireland for the first time in uh years 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 and so yeah my family is uh taking a weekend in whistler to whatever just hang out so bopping out there tell everybody

i say hello 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 a... I'm going to say it was my fault, because I decided to leave CPP North a little bit early, because it was enough. It was enough. Yeah, Bryce, you were originally supposed to fly out this Sunday or Sunday? Yeah, so we would have had a Thursday to Sunday to see ducks. Was that really necessary? I just remembered you were 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 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 play time and that that that that i'm gonna throw the ball for her this has got to be this 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 what do i what do our what do our listeners 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 karuth 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 crew'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 share thoughts? I think we should start with the big news because I think it will be the most timely

for it to be something that goes out this week. 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. All right. So, Bryce, you go ahead and recap the announcement that I'm sure, I mean, I'd be surprised if any of our listeners, actually, I mean, there's some outside of the C++ community that listen that might not.

This news went pretty far and wide. 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 plus plus. And what, what we mean by successor language is 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 incrementally adopt in an existing C++ project. 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++? And it is true that Rust and C++ have a very similar target audience in that they're both systems programming languages. 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. The key founding goal and priority of Rust was memory safety and also to be a more accessible systems programming language than C++. But this interoperability question was not one of these key goals. And I think there's many other interesting aspects to carbon 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 most you know there's i have a few people uh nvidia that have created programming languages that i work with, one of whom is Andre. What language for those that aren't in the know did he create or help create? He helped create the D programming language. And I don't recall if it's Andre or if it's one of my other colleagues who created a programming language. But I was told that for a new programming language to really succeed, it has to be 10x better than the existing programming languages on some dimension.

Not like 10x better like in every way. 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 like you have to be like i was programming in language x and now i'm programming in language y yeah that requires like an immediate rewrite Yeah. 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, 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 that add up to being a much better language. Even though maybe no one of those small improvements would be sufficient to get somebody to buy into, I'm going to completely rewrite all of my software in this language.

And that to me is really the interesting thing about Carbon, is that it promises an incremental path, an incremental adoption, and that it can be incrementally better, that it can still retain a lot of the priorities that we have for C++, like performance and portability, without being tied down by the legacy that C++ has to deal with. But this is actually, this is not the reason why I'm most excited about carbon. I think the interoperability is why I think most people would be most excited about carbon. But I am in 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. And I also think that that's probably true for a language like Rust or a language like Swift. These modern languages that, you know, largely use our modern collaborative tools like GitHub for, you know, decision making and change management and that use better stakeholder models where, you know, there's some sort of core team, but anybody can make contributions and the core team really just makes decisions among a set of options. I think that the difference in having an open model built on modern collaborative tools versus the rather dated ISO-based model that

C++ has, that's really a game changer. And I think that means that Carbon will be able to involve and improve and adapt much better than C++ will be able to in the coming decades so just to be clear do you like as 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 you're just mentioning it as sort of like yes i i believe that the reason that carbon and rust will be successful is because they have substantially better process because it does it doesn't matter if they're better languages than today. It doesn't matter if they're the right tool today. 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. I have far greater confidence in languages that have an agile, modern evolution process. And that doesn't mean that those languages can't, you know, interact with ISO. 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. ISO commonly 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.

You could also imagine that the, you know, standards for something like rust or carbon could be developed outside of the ISO process and, you know, by some separate foundation, and then the results could be contributed to ISO. So these things are not mutually exclusive. I just think that using the ISO process to evolve a programming language is not the correct decision today. It was certainly the correct decision in the 90s for C++. It was definitely the correct decision for older languages like C and Fortran. And in particular, it was certainly much better to have ISOC than ANCIC, because ANCIC was developed solely by a U.S.-based standards development organization. And so its mandate was really very U.S.-focused. And ISO does provide a slightly, you know, broader view. But I think at the end of the day, given the collaboration tools that we have today, given

how software communities operate today, it's just not the right stakeholder model. And I do hope that we can perhaps fix that in the future for languages like C++ and Fortran. 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 thread, a couple different articles. And so there's been, and in the comments of the keynote that's online now, there's been a ton of discussion, obviously. I think the Hacker News post for 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. 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 Rust? 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 big delta between the two. And there's others, but that's sort of the, I think the response to that question. 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 the Carbon team during the Q&A got. And so I'll let you. I'll give the answer for the Carbon team that I don't think you would have gotten during the Q&A, which is the people involved with Carbon spent a decade plus trying to make C++ better. Yeah. Didn't work out. And 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 time and effort trying to make C++ better. 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. Doug Greger, Dave Abrahams, two of the people behind Swift, they used to be deeply involved in C++, and they are prolific software engineers and programmers and programming language designers um so why and they love c++ of course so why did they are they no longer involved now dave is getting back into the c++ world these days, but not so much the committee, at least not that I've seen yet. Well, I don't want to speak for these folks. 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 their efforts were not, that spending more time on ISO C++ was just not worth it, and that they decided they were going to go off and do something else. Now, this is a sort of a unique case, because this is a group of people who are not going off to build a programming language with a different set of goals and priorities. Well, 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. I don't know that we've really properly, formally adopted a set of goals and priorities. 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. I would even argue that D is a different type of language. And Rust is a different type of language. Carbon explicitly aims to be a successor language to C++. Now, and I want to circle back to that question about why Carbon and not Rust.

And yes, interoperability is a big piece of it. But I also think that there's other differences in goals that are significant. Rust has memory safety as one of its key goals. That is not one of the key goals of Carbon. There's a hope that memory safety will be something that can be added to Carbon, but it's not one of the key goals and priorities. I think the focus on performance in carbon is a sort of unique goal among other you know, contemporary programming languages to it. And it's also a goal that I think is to some degree shared by C++. Or at least I think most people involved in the C++ evolution and most

C++ users feel that performance is a priority of C++. Now, the problem is when performance comes into conflict with stability and predictability. I think Carbon will not be afraid to make breaking changes when it needs to, and to weigh the cost of that breaking change and how tooling might help us adapt to that breaking change versus the benefit and performance. I'm not saying that carbon is going to make drastic, huge breaking changes for a you know, a 2% performance gain. I'm saying that if there's some reasonable breaking change that can lead to, you know, 2x, 3x performance in some way in carbon, that that's almost certainly something that I would

suspect carbon will pursue. Whereas in C++, when you have to pick between performance and stability, we pick stability more often than not. Yeah, and 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. And I actually, I think that that discussion 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 things like unordered map and things like unique putter. And that's a true argument, but 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 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 that don't make sense to users. We should be willing to make breaking changes, not just ABI breaks, but breaking changes so that we can get rid of 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 instability is not just one about performance.

It affects the very nature of the language and the complexity and the usability of the language. And it saddens me that we did not have that conversation at Prague. Now, on the other hand, that one discussion was a culmination of many years of discussions. And I think many of the points that I just raised have been discussed over the years. were just framed around the question of performance and did not grasp or remember the full scope of what we sacrifice in the name of stability. Yeah. Yeah.

One of the most, well, I'm not sure if it's the most attractive thing, but just like carbon is going to look so much nicer because they're going to get the defaults right. Whereas, I mean, you'll start off writing. But carbon doesn't have to get the defaults right. If carbon gets the defaults wrong, carbon can fix the defaults. Like the C++, I suspect, got most of the defaults right at the time that we decided upon those defaults. I mean, 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'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. So like I agree that probably when thinking about 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 going to or design decisions that you're going to 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'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 constexpr 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 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 that is going to be super nice and something that Carbon really has going for it. 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 whatever. And you know that there's going to 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 going to look so much cleaner. Oh, yeah, definitely. And you

know, this, this reminds me of something from Sean Parent's keynote, which bookended the conference, and his keynote was called The Tragedy of C++. And I loved it because 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. Perhaps the first time I saw Hana give like a full length talk, or the first time that I saw you give a talk, compete there. But it's definitely in one of the top three. And that was his 2012 C++ Now keynote, where he talks about performance and, you know,

how you get performance out of a chip, and talks about heterogeneous programming, which in 2012 is pretty radical. And then he shows these amazing demos of, I don't remember which Adobe product running on an iPad with rendering this huge image and just very prescient in his predictions of where we needed to be, you know, 10 years later. And yeah, his talk, I was very excited to see him give sort of a talk that called back to that talk. He showed a lot of slides from that 2012 talk in his keynote. I think, obviously, from the title, The Tragedy of C++, Sean feels that we've perhaps not come as far as we would have liked.

I think in some ways we have, and perhaps those have not yet become visible to him. Maybe those are things that you and I see because we're committee members and we see those features going out the door right now. Whereas Sean, who's not as actively involved in the committee these days, but is 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. And I think that's one way in which we on the committee often lose a bit of perspective that we standardize a thing and we're all excited about it. Well, even after we put it in the standard and ship the standard, there's still a pretty long tail for it to get out to users. But anyways, in Sean's keynote, he referenced, I think, a talk by Alex Stepanov where he talked about the complexity of std pair. And he showed 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 62 and alex stepanov was just distraught that something so simple would require 62 lines of code and then in c++ 11 it was what how many lines of code i think i think that was the one that was like 150. Yeah, and then in C++17, it was how many? It was like 500 or something. It like exploded. Yeah, exactly. And it's the same in terms of the size of the C++ standard text,

which has gone up from a few hundred pages to, I think it's near 3,000 maybe now? No, I think it's just under 2,000. It's 1,800 something. Ah, okay. Although maybe C++23 is. Yeah, I think C++23 is probably over 2,000 or it will be once we're done with it. This morning we had the last C++ plenary of the C++23 design cycle where we shipped out the C++23 committee draft and we had 62 motions and we voted in a lot of stuff.

And that was easily 200 pages of things would be my guess. MD-SPAN got in. Congratulations. MD-SPAN is the reason I joined the committee back in 2015. And this is an excellent demonstration of the point of 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 will not be widely available until 2026 probably. So it will have taken me 10 years to accomplish this one relatively simple thing.

Yep. Yeah. Probably wouldn't have taken as long in a non-ISO model. I do not think it would have taken as long in a non-ISO model. Thanks for listening. We hope you enjoyed and have a great day.