Matt Godbolt: Hey, Ben.
Ben Rady: Hey Matt,
Matt Godbolt: How are you doing
Ben Rady: Good
Matt Godbolt: Yet again, we, uh, have our very inspiring beginning to this podcast. One day will be more interesting than this I'm sure, but no. All right. This is, we'll never change.
Ben Rady: We will ne
Matt Godbolt: All right. How about this?
Ben Rady: you're assuming we can be interesting, which I think is impossible.
Matt Godbolt: Sin
Ben Rady: Ack.
Matt Godbolt: Ah, you got it. It's it's Syn/Ack is next you set the Syn and the Ack flag.
Ben Rady: Oh yeah.
Matt Godbolt: Syn and Ack and then I do Ack to say that, but we synchronized our sequence numbers. Anyway, this, this is whole thing is flawed. Anyone listening we've already lost our audience of, of one. So let's try and win them back because today we're gonna talk about Carbon. What is Carbon?
Ben Rady: Carbon.
Matt Godbolt: Carbon offsetting?
Ben Rady: Uh, the element in the periodic table?
Matt Godbolt: It is that it's it's the, the, the least Googleable computer name, computer language name since Go or indeed C and C++, um, you'd think the company who are mainly behind it would come up with a more Googleable name than a, a very common general purpose name, but nevermind, here we are. So Carbon, the recently announced programming language spearheaded by some folks at Google, but, uh, really a community driven project and what it is, what we think about it. What do you think about it? What do you know about it?
Ben Rady: I know, I know very little about what I know about it, and I'm very interested to hear what you know about it, because I know that you have had some, a level of entanglement, quantum entanglement?
Matt Godbolt: Quantum entanglement. Yeah. It is about that.
Ben Rady: Yes. Yeah. Uh, uh, your, your spin direction and it spin direction, or
Matt Godbolt: If you measure one, then the other one changes or something. Yeah,
Ben Rady: Exactly. Yeah.
Matt Godbolt: It's not doing very well here.
Ben Rady: Um, but I, I know that you've had some amount of involvement with it and I'm interested because what I've heard about it is that it is not the very first successor to C++ perhaps one in a long line of potential successors, but it is an attempt to be a successor, um, that works, uh, very well. Uh, the inter interoperability works very well. Um, which to me thinking generally about programming languages, uh, I think is a really important, uh, feature if you're gonna, you know, build something that you are gonna say as a successor is if you can't, you know, people have like very large code bases in language A and you're like, I'm gonna introduce language B. And you're like, well, how do I call my language A code? And the answer is you don't, well, that's the end of that conversation.
Matt Godbolt: You write it to disk and you fire up another process and then read it back out again in the next process, in the old language or whatever.
Ben Rady: Yeah, yes. Right. You open a pipe and then yeah, I'm out now. No, no. Uh, sorry, not gonna do that.
Matt Godbolt: I suppose actually now thinking about it, um, that's kind of the Python two Python, three approach, you know, when you, when Python two, which is the same programming language went to Python three, it's like, yep. Right. Sometime just, you can't import old libraries, you know, unless they use a very restricted subset of the language, but, but you are absolutely right. Yeah. That is Carbon's raison d'etre, uh, which is I think dried grapes, something to do.
Ben Rady: Yes. , uh, it's like an alternative to wine. If you have grapes and you're like, well, I can't make wine.
Matt Godbolt: I see. But I'll make,
Ben Rady: I'm gonna have a reason for being.
Matt Godbolt: So I think, you know, the, we can talk a little bit about what I understand to be the, uh, the genesis of Carbon, but yeah, the intention behind Carbon is to be a successor, a potential successor, as you say. And let's talk a little bit about what other things could reasonably be, uh, successor for C++. And certainly in my opinion, the things that make something, a candidate for succession is it, it has to be a performance based language, right? It has to be something which is fast, cuz most people aren't writing C++ unless they need something to be, uh, low level and fast. And you can reason about performance. You can even make some kind of, uh, guesses as to what the CPU might do with certain language constructs and such things. And you, you need to be able to like poke directly to hardware because stuff is written to hardware and you know, the abstractions have to be able to peeled all the way back to that.
Matt Godbolt: So that's, that's one thing that makes it a successor that very often means that it is not interpreted. It has to be compiled, right? I mean, think that's pretty straightforward. And that has to be no, or minimal run time support needed. Like it should just be a native running program, uh, or at least the ability to turn off all of the bits and pieces that make it need large amounts of run time. So most of the time things that could be considered successes won't have garbage collection. They won't have JITing. Those kinds of things, they will be ahead of time compiled. And what you run is what you compile. There's nothing magical going on behind the scenes after that. So those are the things that, so if we are talking about, uh, languages that fit into that bucket, then, there's the D programming language now D actually does have, uh, some form of garbage collection, but it does look a lot like C++.
Matt Godbolt: Um, but it fix a whole bunch of issues. So that's one potential thing. Um, I mean, C#, you could sort of argue, but I think we can, you know, it was an attempt to,
Ben Rady: I guess, yeah.
Matt Godbolt: to be C ish, like it was kind of the hybrid child of Java and C++ in some ways, but, but of suffers from all of the it's JITed it's it requires a large run managed run time. Uh, yeah. Uh, guess more obviously it's, it's Go and Rust now Go also is arguably a system programs language, but it does need garbage collection. I believe you can turn it off and you can mark large areas of the code not needing garbage collection and stuff. So in theory, you could write an operating system in it, I think. Rust is the strongest contender there, although it's Rust has never tried to set its stand out as being a successor to C++ from a lineage point of view, it is an alternative to C++ in fact it may even be a more of a, a arguably it's more of a successor to C than C++ for some of the things that it does and the way that it does things.
Matt Godbolt: So, so those are the things that immediately spring to mind as potential successors. If I missed one off, I wasn't really, I was jamming.
Ben Rady: I mean, I'm sure that there's a whole host of sort of esoteric ones out there. Um, I'm
Matt Godbolt: Sure that the listener is screaming into their headset and saying aaahhh. What about blah?
Ben Rady: Yes. What about blah? And I will tell you the fact that we're sitting here probably not remembering what they are
Matt Godbolt: Is telling
Ben Rady: Is sort of remind it reminds me of that old thing about their two kinds of programming languages, you know, the ones that people complain about and the, the
Matt Godbolt: Ones that ones that yeah. The
Ben Rady: Other bit. Yeah. Don't nobody cares about. So it's a little bit like that
Matt Godbolt: Now, now I'm thinking of it and you've just given me the break that I needed to actually clear my brain a little bit, uh, going down the dropdown list on Compiler Explorer, there are a number of potential, uh, uh, other languages that, um, that are successors and there's something relatively new called Jacked. And I can't, I, I haven't learned enough about it, which is a bit of, I haven't done my homework for this particular,
Ben Rady: Is that some kind of body spray?
Matt Godbolt: It does sound like.
Ben Rady: An energy drink?
Matt Godbolt: Maybe there's Zig. Zig is a cool, um, uh, one at least, um, that also is not managed and generates code directly. Um, bit more, uh, um, I dunno very much about it other than I was very interested in the way that the, the language itself was, was set up. There's a foundation behind it and, and, uh, you know, it's, that's interesting. Um, yeah, I'm scrolling down the list now. This is awful. Uh, what we got Rust, we talked about Swift, I suppose, is on the list. Um, uh, I don't know, really too much Swift, which is more like an objective C successor, isn't it?
Ben Rady: Oh yeah. Swift swift is like, yeah. I, I, I would maybe if I would, maybe based on my very limited understanding of it, put it maybe in that category, cuz it sort of has all the properties that you talked about and it is have the backing of Apple and they do use it for, you know, iOS applications. I don't know how much it's really expanded beyond that, but you know, certainly in that realm.
Matt Godbolt: And I've also found Nim, there's another one, but that's, again, this doesn't look very C++-sy Nim, Jacked that I've never heard. So of the ones that, um, and, and I know that, um, actually when, when this Carbon was announced, several folks on the various lists sort of said, Hey, you didn't mention X where X was either Nim or Zig or Jacked or something like that as potential things. So we perhaps it would behoove me really to, before we recorded this, to have looked into those a little bit, but nevertheless, here we are. I can speak about the things that I know about only. So there are many things that are arguably successors, but the thing that Carbon has tried to do is exactly, as you say, be a systems programming language that supports all of the features that C++ has plus a bunch more more sensible defaults, more, uh, tractable, syntax, and semantics, um, and fewer ways to go wrong, fewer things to make mistakes.
Matt Godbolt: Just because of like the age of things and with strong bidirectional support for interoperability with C++ and, for those who aren't as familiar with the, what, what that might mean and why it's different for say C++ than most other languages that are compiled. A lot of the things that you can do in C++ when you are using generics, unlike say Kotlin and Java and Scala and Groovy and all those things that share the JVM there, isn't like one way to launder the generics through like an object pointer. And therefore, if, you know, if you write a link list of T, you've got a link list of everything.
Ben Rady: Yeah, yeah. Um, I think you're giving Java a lot of credit here that it doesn't deserve
Matt Godbolt: I'm trying a lot of people.
Ben Rady: Because Java's approach to this is yeah, we're just gonna throw all that information away. That's how the interop works. It's just a list.
Matt Godbolt: Type erasure..I know, but it it's. Yeah, exactly. It's just a list of objects. Right. And, and there's some syntactic sugar over the top that says, okay, you said it was a list of, of um, you know, windows, uh sure. I'll cast it from object and back again, every time it's all like, um,
Ben Rady: Right right
Matt Godbolt: C level of writing generic thing where everything's a void pointer to something and you're like, well, okay, every time you want to get you, what you think it is out, you just I'll let you do that. So, but C++ doesn't go down that route. It's more, um, of a sort of macro expansion. Like at compile time, if you say a list of window, then a bespoke implementation of list is generated specifically for window. And there are loads of tricks that you can do both at compile time because you know, a bunch of things that are true about a list of window that aren't true for a list of widgets. I don't know. But also from the point of view, as, as a programmer, I can write a generic list, um, object that has specializations and can test for things that the T that I've been given either has, or does not have.
Matt Godbolt: And so I can maybe say, Hey, I support this operation. If the T, I contain supports this operation, in which case, now, if you call this on me, I'll do it on all of my contained objects. Or even you could have behavioral changes, which is like, there is an optimization when I know this thing is of this type, then I don't need to sort. So if you call sort of me, I won't do anything or, or I can call some hyper functional sort. So that's, that's cool. That's clever, but it makes it very, very difficult because if you want to, if you're in, in a new language and you say, Hey, I would like to use the C++ list generic on my internal object that I've created in this other language.
Ben Rady: Right.
Matt Godbolt: How does that, how could that even work? They're like that divide seems insurmountable. Carbon is attempting to make it surmountable that you could actually take a generic in one language and use it in the other with an another languages type and vice versa, to some extent now quite how that will be achieved. I mean, in the way that is currently explained is that they are parsing C++ header files using Clang as part of that. And they essentially have a C++ compiler built in. And then there's some generation of like interop code to be allow C++ to call into Carbon code.
Ben Rady: Yes. I mean, as, as we've stated before in this podcast, I know absolutely nothing about C++, but one thing that I have sort of stumbled into accidentally while rummaging around in the programming language closet, is that often with C++ if you use templates, you wind up with a lot of your code in headers.
Matt Godbolt: Exactly.
Ben Rady: And it is specifically because of this, right? Because that there is no compiled version of that generic list that's in an object file somewhere, right? Like there would be with Java, like you said, um, like it's just this header file, that's the definition of it. And it's only when you sort of reify it in a way.
Matt Godbolt: Yes.
Ben Rady: That you actually get the, the real compiled version of it for a specific type.
Matt Godbolt: That's exactly right.
Ben Rady: So, yeah, as you're saying, the way that they're getting around this with, with Carbon is, well, we're just gonna parse the header files.
Matt Godbolt: Parse the header files and potentially even instantiate templates in C++ land from C++ land into Carbon land and pass in some proxy object that allows the, the, uh, uh, the, the two worlds to operate between each other. Now, I think it's worth saying right now, because here I am talking like it exists. Carbon is an idea. Carbon is, uh, a very early alpha design of a language with a very early, not yet totally functional interpreter. There is no code generating being done right now. So a lot of this stuff is theoretical and aspirational, but the folks behind it are, have a great pedigree. There are a number of folks from the C++ community. Uh, there's a number of people from various universities who specialize in programming language design, uh, the community recently, this was announced only, uh, last month.
Matt Godbolt: Uh, and so there have been a huge amount of an influx of people who are interested in helping out it's now open source. So if you were, if I was actually gonna describe Carbon as anything other than, uh, you know, just strongly bidirectional, uh, C++, um, successor, I would, the most important characteristic to me is how the community and the guidelines and the stewardship of the project have been set up. That has been an enormously important part of the process. It's like we, we know that in order to develop this, to make it into a real thing that people can and will use, we need the support and the backing and the input from a wide and diverse group of people from high frequency traders through to, uh, you know, embedded systems engineers who write whatever to, to like web web developers, to goo, you know, the likes of Google and Amazon and whatever, uh, Adobe, um, these folks need to have their input in order to make it a genuine success and not just like a specialization for a, a subset of, of, of people.
Matt Godbolt: Right. And there have been issues before with, you know, language design is hard. Um, the Python way of doing it has been to have the sort of benevolent dictator for life, which has worked pretty well provided that dictator is okay.
Ben Rady: Benevolent?
Matt Godbolt: Benevolent. Yes, exactly. And has, um, um, a lot of, um, thought about the community that they're, they're bringing along with them or, or else they're just in a position where they're responsible for it for on behalf of a company as, as I guess, you know, Python was, it was a Google. Yeah. But, um, or, um, you know, you have a, a very process driven system, like the C++ committee, which has, um, is an ISO standards process. Um, and there's a lot of good things to be said about that process. That is, it is, is very much, um, published if not public, uh, and it is, um, very formal.
Matt Godbolt: And that means that, uh, if you are the, you know, us military and you say, I want a specification for how this language works and will work. And so I can sort of talk to my compiler vendor and say, if I write code and I deploy it in a particular way, it's, is it guaranteed? You know, will you warrant that it works, then we can agree about it because there's, there's the ISO standard, it's the standard document. But unfortunately that brings with it, a lot of bureaucracy, a lot of red tape and necessarily a high barrier to entry. You know, the people that can afford to take the time to participate in that process are usually from a privileged group of, of folks or people for whom have companies with vested interest, which is of course is important too, don't get me wrong, but it's quite difficult for an individual to turn up and say, I think we should do it this way.
Matt Godbolt: Now I know of many individuals, I I'm friends with lots of people who have made suggestions like that, but, you know, again, they've had the luxury of maybe having their company say, yeah, sure. You can spend three, three weeks a year reading through the mailings, getting up to speed. Going to the meeting, presenting your paper, um, defending it against the rest of the, the committee and then ultimately getting it through. And it's a long process. People you know, um, I think it was, uh, Bryce, uh, Adelstein Lubeck who joined the committee like 12 years ago to get one feature in the, he wanted, which was like some multidimensional iterator, a multidimensional static size array. And it only just went in and that means it'll probably be implemented in the next, you know, revision. And you might be, you might be able to rely on it in compilers in like five or six years time. And that's a long, long, long time. Whereas, you know,
Ben Rady: So now he can finally quit?
Matt Godbolt: So now he can quit. That's right. Yeah. but, um, but you know, again, there's a reason why that exists. It's a reason why it is that way, but for rapid development of a language and new ideas and trying that stuff out, you need something new and you need a new vehicle for it. And the, the Carbon, uh, community is set up to hopefully, hopefully be that. Um, so that's interesting and exciting to me to see what will come out of that.
Ben Rady: I feel like we've talked about on another episode about languages and sort of language choice about how important community is in programming languages. Right. And I think I've made the argument before that it's like, you know, whatever that community values is, what you will be forced to value if you use that language.
Matt Godbolt: That's very true.
Ben Rady: True, right? So if they value types, you will use types. If they value, uh, you know, uh, fast feedback loops, you will have fast feedback loops. Like, you know, if they value testing, you will value testing. You won't really have much of a choice. You can fight against it and sometimes get away with fighting against it. Um, it's certainly possible to sort of, you know, go against the, the grain when it comes to using technology of any kind. Um, but there will be this ever present almost wave-like force pushing you toward whatever it is that they want to do. And for me, that is almost more, an important factor than things like language features or, you know, uh, tooling specifics, because it's like, whatever state it's in right now, there's a possibility that it's gonna change. Now, obviously as languages get more mature, and as we were just saying about like, things like the C++ committee, that change definitely has a certain pace to it.
Ben Rady: But, um, but whatever it is that they value and whatever it is that, that, that, uh, group of people want, um, is, is gonna have an effect on you if you work in that language. And so like understanding the specific individuals behind the language or the company behind the language or the, uh, the mode that they all use to interact, um, you know, the way that they make decisions, the way that they make changes, the way that they, uh, you know, add those changes, you know, is it like a Python, two Python, three thing where it's gonna be like, Nope, we're breaking everything. And if you don't like it, suck it. Yep. Right. Yeah. Yeah. Which might have been the right decision, but that was definitely, that's like a call, like you made a call there and it's gonna be this. So understanding those things is super important to me.
Matt Godbolt: I completely agree. I completely agree. And in fact, you talking about, again, the Python two Python, three split, and the fact that somebody just said, no, we're doing it. You know, that is sort of, sort of what this is about, uh, in as much as the problem with C++ is also one of its greatest strengths. I mean, one of my, one of my talks is on what C++'s superpower is. And I make an argument rather, tongue in cheek, but only a bit tongue in cheek. I dunno what that the, the C++ is superpower is in fact that really annoying backwards compatibility. That means that we drag the, you know, the 30 years of history around with us. And half of the things are, have silly defaults because we didn't know better. And we can't now change them because that would break old code and no one has yet come up with a way that can satisfactorily to everybody, allow us to migrate slowly and make incremental changes without losing that really important backwards compatibility that lets you pick up code from 30 years ago and bring it into your code base, or even more, more sort of, um, specifically problematically in this case.
Matt Godbolt: Um, if you have a library that was built with C/C++ compiler, some number of years ago, and you have subsequently lost the source code or never had it because it was a vendor, the vendor went out of business. Uh, you have a header file and you have an opaque dot O file or a dot lib file or dot a file or whatever. And you're like, well, my business depends on this options pricing library or this insurance, uh, algorithm thing. And what C++ guarantees pretty strongly is that a modern C++ compiler can consume that header file and know how to call the the functions that are defined in that binary. That is the application binary interface, the ABI, the way that things are laid out in memory, the way that which registers are used for what rit purpose and all of that stuff that comes together has not changed even in the presence of compiler changes.
Matt Godbolt: Even the presence of, uh, language changes. It guarantees that, and that's super important to a very small number of folks, but to them, it's, it's absolutely critical, right? They don't have the source, they haven't got the wherewithal to reverse engineer or whatever. And so the ABI can't be broken. And in fact, it's only been like teased, gently broken like bent a little bit once in my knowledge, which was when, uh, a, a, a fundamental flaw in the way standard strings work was fixed. And that even to this day, there's command line options to kind of go, no, no, no, no, go back to the other way, because I still need to link with it or whatever. And you can sort of isolate, but like in general, there are problems in changing the ABI. On the flip side, there are a number of standard containers and standard algorithms who are pessimized by decisions that were made from before.
Matt Godbolt: And we can't now change because the ABI would need to change alongside them in the particular instances of those, those, those things, which means that things like hash maps, which, you know, are used absolutely everywhere. The standard one is never gonna change. And it's nowhere near as performance as it could be. If you were to sta you know, sit down and write your own one from scratch. And of course, many people have done, and you can pick up any number of hundreds of different hash map libraries around, which is a thing, but how much nicer is it to just, just be able to rely on the one that's in the language and say, this gives me everything I need. And it's about as performance as I ever would need. Now, I, I still treat unordered maps in C++ like that, unless I prove otherwise, I'm, I'm fine with the performance of it. But for a lot of people, it would be like, well, it's, it's silly. We're leaving performance on the table here because we can't make a change because we might break someone's code from 1998. And that, I mean, not in that specific case, but, you know, like there are things like that that have caused issue.
Ben Rady: Most of my C++ is from 1998
Matt Godbolt: That's right. Yeah. So your C++ you could bring it on , you should bring it along next time. We we'll have a little play with it. but you know what I mean? So, so understandably there are frustrations, and that's almost one could argue as sort of a schism between the companies and, um, and, and, and individuals for whom that has never been a problem. And I mean, foremost among those, if we're being honest, is, is Google who have long, um, proselytized the idea of like building everything from source all of the time and living at the head revision of stuff, you know, Titus Winters, um, the manager at Google, um, I forget his title, sorry, Titus. Um, but who's in charge of all the things that I'm I know of at Google to do with C++ has always said, you know, we live at head here.
Matt Godbolt: That's our development policy. There's no version X of library. It's just like one monorepo everyone's checking in code all at the time. Everyone's making sure their code works with everyone else's code at the top. And that makes sense. And if you have all the code, brilliant ABI is unimportant to you, because you never consume a binary from somebody else. You, you always have just built it from source. So you're like, Hey, I wonder what happens if we change this compiler flag that would, you know, sort everything alphabetically in, in memory or whatever, right. In terms of the fields of be like, okay, cool. Let's just try it make, brrrrt, a hundred years later. Here's my executable. I've just changed everything about it. And to an extent, whenever I've worked, and this is probably as a result, having worked at Google, whenever I work at a new company, one of the first things I'll do is set, set up the, as near as I can get that again, you know, Hey, if I type make it, fetches the version of the compiler that I want everything to be built with.
Matt Godbolt: Yeah. And then it builds everything from source, wherever it can with that version of the compiler. And then now we can make, again, these changes where you can make a, a, a change and so ABI has not been important to me. And, um, and so Carbon, I think has come out of a sense of frustration to some extent that that C++ has kind of reached this point where no, it's in a local minima now, and it can't get out of it. And so we need to do some sort of simulated annealing, bang it, ever shake everything around. Introducing a new language is one of those, uh, but also a sense of like, maybe there's a different way to develop a language and a more community driven approach might be appropriate here at this stage, in the language. Maybe it'll change. Maybe it'll be a nicer standard in 20 years time, maybe nothing will happen.
Matt Godbolt: Maybe. And this has been said by, uh, Chandler Carruth I think, um, maybe if the best, if, if C++ gets better as a result of having ideas being tried out in Carbon, even if Carbon never goes anywhere, that would still be a result that would still be a success. You know, this is not a zero sum game, right. If you, if you don't like C++, and you wanna try something else, try Go try Swift, try Rust, try, Kotlin try Scala, whatever. Right. This is, we're not. And I say, we, I mean, I'm peripherally involved is, is, is about the best thing you could say. Like I'm, I'm aware of it a bit more. Um, yes, we won't be taking anything away from C++ there's an argument. There's some resources that's coming away from it. But I think the, the, the folks who have stopped working on C++ as much, and, and started to look at Carbon with folks who were already had one foot out of the door, perhaps in terms of what they're doing. So there's maybe that argument.
Ben Rady: Yeah. I, I, I think people also discount the, um, effect that things like this can have on people's motivation and enthusiasm. Right. Like, you know, if you, if you inspire people and you get them headed in a, in a direction, I think it's very misguided to be like, well, but those people could be working on this thing and it's like, no, they wouldn't cuz they just don't care. Right, right. Right. Like it's just, it's just, it's just not the same thing.
Matt Godbolt: Exactly. Exactly. There is definitely a lot of excitable people and you know, the meetings that I've been to have been filled with people who are enthusiastic and it's not to say that there aren't enthusiastic C++ core developers either. Right. But, um, right. Some of those folks, uh, uh, have been doing it for like 20 odd years and maybe, maybe they wanna change, so who who's to take away from them. So from a point of view of, um, actual features of Carbon, what are the type of things that it's, uh, presenting that I'm personally excited and interested about top of that list is actually generics. I know we sort of pooed them a little bit. Oh, okay. When we talked about Java and they kind of like the fact that everything gets laundered to an object star well, both Rust and I think Swift are fully compiled languages and don't have like an Uber based type, like Java does like object, but they do support a, a more, um, generic, generic system.
Matt Godbolt: So that doesn't make any sense at all. Again, so a, a generic system where you can have a container of something where there's something isn't known at compile time, but yet um, the, the, something is constrained. Now in C++ world, you know, you can actually literally put any type you like in that T parameter I could put in, in there, I could put float in there. I could put literally, literally any, any type can go in there and provide that it compiles and makes sense. And that's decided at compile time when you instantiate it, then that's a valid thing to do. But I can't later on, uh, support a dynamically chosen thing. I can't load up a library and go, oh, now I want a T of those. It's like, no, you, you can't make a, sorry, you, you can't make a list of those types that you just loaded in from a DLL or something like that.
Matt Godbolt: Cause as we discussed, it requires running the compiler to generate something for them. A technique that sometimes is handwritten in C++ is called, uh, type erasure where you kind of force a set of functions, virtual functions in real C++ terms that implement all of the things that your generic T needs in order to be used. So for example, if you have a list of something, maybe you need to be able to copy something. So you need to be able to copy an object from one place to another or clone it. Um, you maybe need to be able to compare it and you write these as methods and each method has to be implemented by that type. And as it happens, you can now use templates to adapt any T to that, conform it to that interface, which is the erasing part. But then the generic algorithm you're handing to, maybe it's a sort algorithm just purely works in terms of those functions that you've handed it. So it just calls functions. And so now there is no strong link between a sort that takes a sortable. Like it would be an interface sortable interface and, um, and any object that, that, that can be adapted to provide a sortable.
Ben Rady: Yeah. So in that case, the, the sortable interface and the sort function could be compiled and live in a binary somewhere. And your sort of third party code could reuse that
Matt Godbolt: Exactly...Exactly right.
Ben Rady: Uh, in a generic way.
Matt Godbolt: Exactly right. And, and so there's, you can do this by hand, fairly straightforwardly by enumerating all the things you need, your thing, your, your type to do, writing a sort of virtual interface type that wraps that, then you write your algorithm in terms of that virtual interface type, the, you know, sortable type. And then you write your little one template that says, given any object, I will adapt that object. I will hold it on onto one of those objects and I will present the virtual interface for this particular type. So that's the kind of binding part, and that's all very hard to do. And it's, it requires you to do it by hand for every type you want to implement, which is a pain, but it has a certain amount of, uh, of, of benefits. And it's used internally in the SDL, in a couple of places. What Rust and what, um, and I'm more weak on Swift do is they allow for declaring this the language level and letting the compiler essentially say, I can, I can adapt your type to fit this interface because it provides all these things.
Matt Godbolt: And then the thing that I will present is just a block of function pointers to the algorithm. And I will do that for you automatically, right? I'll take this, uh, this, this, this object that you say, and it's got an implementation of this interface somewhere else. And I'll say, okay, this, this data and this block of function pointers go together. They're not tied as they are in C++ with virtual function pointers where it actually has to live inside the object somewhere, they can be disparate. And these are called trait objects. These traits allow you to adapt any old chunk of data to any interface. And that can be done at, at this time. And that's kind of cool now it's it's. And so right. Coming all the way back Carbon is gonna support a flavor of that. So you'll be able to write code that says I would like to make, I would like to sort something, this is the interface that anything that comes into me needs in order to be sortable like a less than operator and a swap between two things, whatever that may be.
Matt Godbolt: And now I can sort those things. And, um, there's a very small change between making that like C++ templates where it is instantiated at compile time. I know the types and therefore the compiler knows the types. And for every type that wants to be sorted, I will make a new sort routine that only deals with that type. And then if you don't use, I think it's an exclamation point inside, like the, the, the, the sort of like the name of the parameter or the type of the parameter, then it says, okay, no, what I'll do is I'll make one of these adapters in the middle and now I can take any object you, you like, and I will compile the sort function once. And once only, and it will work with the, the interface and then I will adapt for the interface and make a generic that, that I, that fits it again.
Matt Godbolt: I think in Rust, it's called traits objects, uh, in Swift, they call them witness tables. I think there's something like this against a little table that that's like automatically generated that, that sort of bridges the gap, glues, uh, a specific instance type to a generic interface type at the binary level right now it's never gonna be as performant because you're always going through a layer of indirection, right. And all problems can be solved by another layer of indirection. Right. But it's a choice you can make. And unlike, say C++, where if you want to do something most of the time, if you're just writing idiomatic C++ if you want to do something generically, you have a choice. You either go, I will make a virtual interface and everything that wants to go through my system has to inherit this virtual interface.
Matt Godbolt: Or you say, no, I will use templates. And now I'm gonna use compile time types. It's a very different way of writing. It's a very different set of error messages and, and, and the code is vastly different. Um, this is trying to unify a bit more is my understanding so that you can make that choice without having to essentially rewrite like, Hey, maybe, maybe this is performance critical, or maybe it is only used in places where I, I do know ahead of time what the actual concrete types are. So I can use the template-y generic system, uh, or no, actually it's not performance critical. Uh, it's bloating my binary with 300 different copies of, you know, this function for every type of thing I call it with. Let's just use the generic sort of Java style thing. And again, it's slightly more type safe than Java cuz instead of laundering it through the base pointer, that's an object.
Matt Godbolt: It launders it through a, an interface that is necessarily the subset of things you needed. So it's always, at least got all of the functions that you you've declared you needed and the compiler will check that. So I'm excited about that because I bang on all the time about the cost of virtual interfaces and things like that. And then, you know, every now and then I'm, I'm like, well actually I can't use my nice shiny interface type anymore cuz it isn't, uh, performant enough. And now I'm gonna have to like in order to have a test version and not a test version, I'm gonna use a template and oh, now I have to, to rewrite it. Now I don't like it. It'd be nice just to change it around. So, so that's what I'm most excited about when it comes to, to Carbon. But again, it's a long way off. No one listening to this should think that they can go off and uh, build something with Carbon. They can certainly go to Compiler Explorer and they can drop down Carbon and then they can see the assembly view. Isn't actually assembly view because there is no compiler. The assembly view will,
Ben Rady: I was gonna say, if there's just an interpreter.
Matt Godbolt: It's just an interpreter. So you see like the internal states that the interpreter goes through, as it does all of the various language laws of like, Hey, this can be substituted with this. So I'm substituting that with this. And so you mean this and step steps and eventually, obviously it starts actually executing the program in an interpreted fashion and you do get a result, but it's very, very early days. But then the also it's already has LLVM inside of it in order for it to pause, uh, sorry, Clang and therefore LLVM so it's pausing header files. You can actually show that the interrupting principle is looking like it would, you know, it smells like it's going the right way. And so it can't be too long before somebody says, why don't we generate some code? Why don't we just use the LLVM and generate actual, uh, code. And so I'm, I'm looking forward to that day.
Ben Rady: Uh, are there any other like language features that you at least know about with Carbon?
Matt Godbolt: So the thing that keeps coming up on all of the, the lists and certainly on the Twitter verse, when it was first announced is Carbon doesn't currently have support for strong memory safety. So Rust's unique selling point is that it has a pretty strong type based ownership tracking system called the borrow checker, which is responsible for knowing which parts of the code in any control flow may have references to data and asserting that the data data's lifetime outlives, the, the things that have references to them. So no more dangling pointers. Um, and, um, that's great. You get a compiler error that says, Hey, you passed this to this function, which then took a reference to it and held onto it in like some local state variable. And then it fell off the stack and that's an error, right? And C++ you compile it with all these sanitizers and at run time, it'll go, oh, maybe that happened.
Matt Godbolt: And that's, that's the terrible time to discover that kind of error. So Rust wins on, on that front for certain. Um, it can be quite frustrating to phrase your code correctly in Rust so that you can prove to the compiler that you haven't made a mistake. And certainly, you know, when I first looked at Rust, there were occasions when the borrow checker was too stringent and was couldn't prove like there was no flow in which you escaped a function and it hadn't taken a reference to a, to something in, in under certain situations. But I believe nowadays it's a lot better. So maybe, maybe my sort of like, um, my experiences are, are gone, but there, there are definitely situations where it's hard to prove like doubly link list, I think is the classic example where, you know, every, every pointer has a pointer back to the previous one.
Matt Godbolt: And if it's a circularly doubly link list, it's like, well, what's the, what's the life's, how can we prove that it doesn't refer to some old data because there's no way of breaking the link. And I don't actually understand how that works. There's all sorts of annotations and things. So I'm, I'm not gonna talk more, but popping the stack. Carbon, doesn't try to solve this problem, partly because C++, and it's strong interoperability with C++ kind of makes that hard, right. Essentially any call to C++ would be quote unsafe given right. The, uh, the Rust model, right. Again, if you're in Rust and you're calling out to a C API it's unsafe by, by, by you can't safely track the memory patterns of calling an arbitrary function. It has no idea what it does similarly with the C++ side of things.
Matt Godbolt: So the only things it can do is do, you know, make, makes some of the defaults like uninitialized variables. So in, in C++, or, and C if you just go int i semicolon and then that's got no value at all is uninitialized. And if you're very, very, very lucky, it's, uh, it's just, uh, some random value off the stack. And if you're very unlucky, then the compiler said, well, you've made a mistake there and you're not allowed to make mistakes. So I'm gonna take advantage of that and optimize it out in some crazy way. So it's the dreaded undefined behavior, but Carbon has gone with like, no, we're gonna actually initialize everything. If you want something to be not initialized, that's a hard, like unsafe block type thing you have to say, no, I don't want this to be initialized. It's absolutely performance critical that we never initialized this. Fine.
Matt Godbolt: Right. Yeah. Okay. Um, and you know, there will be, things will be, there will be bounds checking type stuff that will be in the language and whatever. And of course it'll have more, we can design it for address sanitizer style. Um, um, support from the get go, and maybe make it a little bit more amenable to that and require less binary instrumentation type stuff. But there is a desire, there is a desire to move towards a, uh, uh, a safe subset of, of, of, of the language, which can be said to be, you know, provably, uh, memory safe. So, but it's not a great, um, it's not a great, uh, uh, story right now. And I think a lot of people were like, what the heck? You're inventing a new language here we are in 2022. Yeah. And we are still gonna have all of the overflow errors that we had and the use after free and the double free and the leak problems.
Matt Godbolt: And like, I understand where people are coming from, but also in my experience limited as it's been in the last few years, even modern C++ has come leaps and bounds in that direction, right. With the sanitizers. But also with all of the facilities, the language now provides, it's a lot harder to make the kinds of mistakes that were trivial to make before, like, you know, by using smart pointers and annotations. And again, the, the sanitizers. So I'm not as concerned about myself personally, maybe just, maybe I'm in a luxurious position of like, none of my code has, uh, user input banged into it all day. So I'm not, parsing, you know, potentially adversarial messages from a network. And so, you know, maybe I'm just sleepwalking and, you know, , if anyone with half a brain, uh, tried to hack anything that I had on the internet, uh, that was written in C++, then they would immediately discover all of the overflows that I haven't. So maybe I'm just, um, uh, blind to that.
Ben Rady: Does Carbon have its own standard library or is it just gonna piggyback off the C++ library? How's that gonna work?
Matt Godbolt: So my understanding now we're into a bit that is, is even more, um, speculative than most of the stuff I've been talking about. Um, obviously they want to be able to use the STL directly straight away, but I think they really want to have a sort of more batteries included, feel, um, and have libraries that do more things than say the standard library does in C++. Plus I think that's always been a, another point of contention is like the STL is necessarily, no, not necessarily the SDL is relatively limited. Uh, it has a great set of amazing algorithms and the way that you can plug them together and you can build stuff is wonderful, but, you know, and, and there's an argument that says, if you want to tell whether or not this string is inside this other string, then you could use the generic algorithm that find takes a sequence, uh, uh, one range, that's a, that's a bounded sequence and another range, that's a bounded sequence. And it tells you whether or not they intersect in some way. And it's about 12 lines to set it up nicely. And I'm sorry, it's not 12 lines, but you know, I'm hyperbolic here. Um, right. You know, and, and, and, um, you know, and so why would we ever need to have a string dot includes other string.
Ben Rady: Right. Right.
Matt Godbolt: But to me, that's facile, right? That's, that's, that's not useful. It's beautiful and it's elegant, but everyone wants to say, does this string end with this other string or does, is this string, the prefix of another string, which now has actually been added to string. And there are thousands of functions that have been added to string, which is obviously another problem. So it's hard to find the balance. It's hard to find the balance. It is, but I think C++ really suffers from not having a lot of, uh, uh, of like what would be straightforward stuff, you know, like, Hey, I want a 2d graphics library. I just wanna draw pictures on the screen. I wanna open a window and fill a triangle. And you're like, no, no, no, no, you can't do that. That's not built-`in, you can, you can do console out, that's it.
Matt Godbolt: Right. Nothing else. And that's when you're trying to demo to folks, you know, stuff, it's just nice to be able to, to, to, to, to draw a Mandelbrot set in a couple of lines of card or stuff like that. But, you know, networking, there's no networking. It is coming soon to C++, but it still isn't there. And it's, there's a lot of degrees of freedom in networking, of course, but it does seem silly. You can't write like a, a modern web server without pulling in hundreds and hundreds of bits of other things. There's nothing there in the, in the, the standard.
Ben Rady: So I is Carbon gonna have a calendar API and more importantly, is it gonna be called Dating?
Matt Godbolt: Oh, the Carbon dating library. It's gonna have to now. Yes. You heard it here first folks. I mean, there have been a number of gags you could imagine about Carbon.
Ben Rady: I mean, it's a whole new opportunity for puns with this language, right? Like you just...`
Matt Godbolt: For the longest time, it was an internal name. And I don't think we had any thought that it would actually be the external name, but you know, the story about internal names where it's not really good, external name is like, well, they tend to stick and then you're like, well, we're kind of used to it now. Yeah. I think I've told you about this before. That, that I, whenever in whenever I'm stuck trying to think of a name for something, I will make up something silly. And oftentimes it's Bob and Ian, they're just the two words, you know, they're my, they're my personal silly metasyntactic variables, especially as I've tried to move away from the, the other ones that everyone uses. Right. For various reasons. But, um, I think probably still at, at our previous trading company, there is a system that was referred to as Bob still, because we could never think of a proper name for it. And so it stuck. And now that's Bob. Um, I think it was some simulator of some exchange. Uh it's like, it makes no sense. It's an agent that makes us SIM an exchange, do something. And I, I would just call it Bob for now with one of the, the intern type folks. And I'm like, yep. Well, that's what it is now.
Ben Rady: Yeah. Bob forever.
Matt Godbolt: Cool. Well, that's about all I know about it. I'm excited. I'm not very involved in it. I'm only involved in it because Compiler Explorer wanted to be a day, one feature when they launched. And, um, I'm really interested in seeing where it goes.
Ben Rady: Yeah. Yeah. Okay. Well, is there like, uh, like an upcoming inflection point for Carbon, a date that we should be looking out for, or, uh, a release or something like that?
Matt Godbolt: I don't believe so. No. I think people can just Google Carbon language and you'll find the GitHub repo where everything is. There is a, um, yeah, there's a lot of documentation aspiration on otherwise on that site, as well as the code, you will need basil or basil to build, which is a bit of a contention for me. Um, but that's a whole other conversation. And, um, there is a discord that you can join again, is a very strongly enforced and carefully set out code of conduct with the moderation panel and stuff. So it's a safe space for folks to come out. If you're just interested in, um, what it looks like to see a language and its early in its early infancy. Uh, if you, if you sign the CLA there's the client license agreement, whatever it is to become a contributor to it, then I think that you can get to join the, um, the weekly meeting that we have. Uh, I've certainly noticed some, some people, some of the Compiler Explorer, implementers actually who got like a bit of an early heads up that that Carbon was coming in the pipeline because of, um, well, because of Compiler Explorer and um. I've now have now joined and are involved in that. So I, I'm excited to see that kind of synergy, uh, folks that I I know are, are very interesting and interested in this, um, joining. So come along and join.
Ben Rady: Yeah. Sounds. It sounds super cool. Looking forward to see what happens with it.
Matt Godbolt: All right. Well, um, until next time, I guess
Ben Rady: Until next time.