Two's Complement - Carbon Footprint

Episode Date: September 14, 2022

Ben and Matt talk Carbon, the new language backed by Google, designed to be a successor to C++. Matt discusses his involvement with the project. Ben asks questions and cracks wise.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are you doing? Good. Yet again, we have a very inspiring beginning to this podcast.

One day we'll be more interested in this, I'm sure, but... No. No. All right. We'll never change. We will never... All right, how about this? You're assuming we can be interesting, which I think is impossible.

Sin. Ack. Oh, you got it. It's Sin Ack is next. You set the Sin and the ACK flag. Oh, yeah. SYN, SYNAC, and then I do ACK to say we synchronized our sequence. Anyway, this whole thing is flawed. Anyone listening, we've already lost our audience of one. So let's try and win them back because today we're going to talk about carbon. What is carbon? Carbon.

Carbon offsetting. The element in the periodic it is that it's it's the the least googleable computer name computer language name since go or indeed c and c plus plus um you'd think the company who are mainly behind it would come up with a more googleable name than 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 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? I know very little about what I know about it. And I think about it what do you know about it 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 yeah it is about that yes uh-huh uh your your spin direction and that spin direction or if you measure one then the other one changes or something yeah exactly it's not doing very well here 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 that works very well. The interoperability works very well,

which to me, thinking generally about programming languages, I think is a really important feature if you're going to build something that you're going to say is a, build something that you're going to say is 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 going to 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.

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. Right. You open a pipe and then, yeah, I'm out. No. Sorry. Not going to do that. I suppose actually now thinking about it, that's kind of the Python 2, Python 3 approach.

You know, when Python 2, which is the same programming language, went to Python 3, it's like, yep. Right. Sometimes just you can't import an old libraries, you know, unless they use a very restricted subset of the language but but you're absolutely right yeah that is carbon's raisin detra uh which is i think dried grapes something to do yes uh-huh it's like an alternative to wine i see you have grapes and you're like well i can't make wine but i'll make i I'm going to have a reason for being. So I think, you know, we can talk a little bit about what I understand to be 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 successors for 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 because most people aren't writing c++ unless they need something to be uh low level and, and you can reason about performance, you can even make some kind of guesses as to what the CPU might do with certain

language constructs and such things. And you need to be able to poke directly to hardware, because stuff is written to hardware, and the abstractions have to be able to peel all the way back to that. So 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 i think that's pretty straightforward and there has to be no or minimal runtime 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 runtime. So most of the time, things that could be considered successes won't have garbage collection. They won't have jitting, 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're 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++ um but it fixes a whole bunch of issues so that's one potential thing. I mean, C sharp, you could sort of argue,

but I think we can, you know, it was an attempt to be C-ish like, it was kind of the hybrid child of Java and C++ in some ways, but it suffers from all of the, it's jitted, it requires a large managed runtime. Guess more obviously 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 as not needing garbage collection 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 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 so so those are the things that immediately spring to mind as potential successes. If I miss one off, I wasn't really jamming. I mean, I'm sure that there's a whole host of sort of esoteric ones out there. I'm sure the listener is screaming into their headset and saying, what about blah?

Yes, what about blah? And I will tell you, the fact that we're sitting here probably not remembering what they are is telling. It reminds me of that old thing about there are two kinds of programming languages. And I will tell you, the fact that we're sitting here probably not remembering what they are... Is telling. It reminds me of that old thing about there are two kinds of programming languages, you know, the ones that people complain about and the ones that people don't. The ones that, yeah, the other bit. Yeah, nobody cares about.

So it's a little bit like that. 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. Going down the drop-down on compiler explorer there are a number of potential uh other languages that um that are successors and there's something relatively new called jacked and i can't i haven't learned enough about it which is a bit of i haven't done my homework for this particular that's some kind of body spray it does sound like it doesn't it yeah maybe there's zig zig is a cool um one at least um that also is not managed and generates code directly um a bit more uh um i don't know 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 do we got rust we talked about swift i suppose is on the list i've uh i don't know really too much about which is more like an objective c successor isn't it oh yeah swift swift is like yeah i i would maybe if i would maybe based on my very limited understanding of it put it maybe in that category because it sort of has all the properties that you talked about and it does have the backing of apple and they do use it for you know ios application i don't know how much it's really expanded beyond that but you know certainly in that realm and i've also found nim there's another one but that's again it doesn't look very c++y nim jacked yeah so of the ones that um and i know that um actually when when 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 successes but the thing that carbon has tried to do as 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 tractable syntax and semantics, and fewer ways to go wrong, fewer things to make mistakes, just because of the age of things.

And with strong bidirectional support for interoperability with C++. And for those who aren't as familiar with 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're 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 linked list of t you've got a linked list of everything

yeah yeah um i think you're giving java a lot of credit i i'm trying i'm trying a lot of people java's approach to this is yeah we're just going to throw that information away that's how the interop works type erasure it's just a list i know but it's yeah exactly it's just a list of objects right and then 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 right i'll cast it from object and back again every time it's like um right the 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 yeah so but c++ doesn't go down that route it's more um right 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 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 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 to me i won won't do anything or I can call some hyper functional sort. So that's cool. That's clever. But it makes it very, very difficult because if you're 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. Right. 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 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 allow C++ to call into Carbon code. Yes. I mean, 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.

And it is specifically because of this, right? Because 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. 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 yes that you actually get the the real compiled version of it for a specific type that's exactly yeah as you're saying the way that they're getting around this with with carbon is well we're just going to parse the header files 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 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 uh and so there have been a huge amount of an influx of people who are interested in helping out it It's now open source. So if I was actually going to describe Carbon as anything other than a strongly bi-directional C++ successor, 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 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 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 subset of people. Right. And there have been issues before with, you know, language design is hard. The Python way of doing it has been to have the sort of benevolent dictator for life, which has worked pretty well, provided the dictator is okay. Benevolent. Benevolent, yes, exactly. And has a lot of thought about the community that they're bringing along with them,

or else they're just in a position where they're responsible for it for on behalf of a company as i guess you know python was it was google but um or um you know you have 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 very much published, if not public, and it is very formal. And that means that if you are the US military and you say, I want a specification for how this language works and will work. And so I can 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 a standard document but

unfortunately that brings with it a lot of bureaucracy a lot of red tape and necessarily a high barrier to entry and the people that can afford to take the time to participate in that process are usually from a privileged group of folks or people for whom have companies with vested interests, which is, of course, 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. Now, I know of many individuals.

I'm friends with lots of people who have made suggestions like that, but again, they've had the luxury of maybe having their company say yeah sure you can spend three three weeks a year reading through all 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's a long process. I think it was Bryce Adelstein-Lelbeck who joined the committee like 12 years ago to get one feature in that he wanted, which was like some multidimensional iterator

or multidimensional static size array. And it only just went in. And that means it'll probably be implemented in the next revision. And 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...

So now he can finally quit. Now he can quit. That's right. Yeah. 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 Carbon 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 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? 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. That's very true. Right? So if they value types, you will use types. If they value, you know, fast feedback loops, you will have fast feedback loops. 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. It's certainly possible to go against the grain when it comes to using technology of any kind. 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 going to 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. But whatever it is that they value, and whatever it is that that group of people want, is going to 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 mode that they all use to interact, you know, the way that they make decisions, the way that they make changes, the way that they, you know the way that they add those changes. Is it like a Python 2, Python 3 thing where it's going to be like, nope, we're breaking everything.

And if you don't like it, suck it. Which might've been the right decision, but that was definitely, that's like a call. Like you made a call there and it's going to be this. So understanding those things is super important to me. I completely agree. I completely agree. And in fact, you're talking about, again, the Python 2, Python 3 split and the fact

that somebody just said, no, we're doing it. You know, that is sort of what this is about in as much as the problem with C++ is also one of its greatest strengths. I mean, one of my talks is on what C++'s superpower is. And I make an argument rather tongue inin-cheek but only a bit tongue-in-cheek i don't know what that the c++ is superpower is in fact that really annoying backwards compatibility that means that we drag the you know 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 sort of specifically, problematically in this case. If you have a library that was built with a 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. You have a header file and you have an opaque.o file or a.lib file or.a file or whatever. And're like well my business depends on this options pricing library or this insurance uh algorithm thing yes um yes and what c++ guarantees pretty strongly that it is that a modern c++ compiler can consume that header file and know how to call 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 purpose, and all of that stuff that comes together has not changed, even in the presence of compiler changes, even the presence of language changes. It guarantees that. And that's super important to a very small number of folks,

but to them 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, he's gently broken, like, bent a little bit once in my knowledge which was when uh 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 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 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 going to change and it's nowhere near as performant as it could be if you were to start 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 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 performant 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 and so most of my c++ is from 1998 that's right yeah so you'll see but you can bring it on you should bring it along next time we'll have a little play with it but you know what i mean so so understand, there is frustrations and there's almost one could argue sort of a schism between the companies and individuals for whom that has never been a problem. And I mean, foremost among those, if we're being honest, is Google, who have long 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, the manager at Google, I forget his title.

Sorry, Titus. But who's in charge of all the things I know of at Google that are to do with C++ has always said, you know, we live at head here. That's our development policy. There's no version X of a library. It's just like one monorepo. Everyone's checking in code all of 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 always have just built it from source. So you're like, hey, I wonder what happens if we change this compiler flag that would sort everything alphabetically in memory or whatever, right, in terms of the fields. You're like, okay, cool. Let's just try it.

Make. 100 years later, here's my executable. I've just changed everything about it. in memory or whatever right in terms of the fields of you're like okay cool let's just try it make 100 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 of 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 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 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 the c++ has kind of reached this point where no it's in a local minimum now and it can't get out of it and so we need to do some sort of simulated annealing bang it every 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 an iso standard in 20 years time maybe nothing will happen maybe and this has been said by uh chandler caruth i think um maybe if the best 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 anywhere, that would still be a result.

That would still be a success. You know, this is not a zero-sum game. If you don't like C++ and you want to 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, peripherally involved

is about the best thing you could say. Like, I'm aware of it a bit more. Yes, we won't be taking anything away from C++. There's an argument that some resources are coming away from it. But I think the folks who have stopped working on C++ as much and started to look at Carbon were folks who already had one foot out of the door perhaps in terms of what they're doing so there's maybe that argument yeah i i think people also discount the um effect that things like this can happen people's motivation and enthusiasm right like you know if you if you inspire people and you get them headed 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 because they just don't care right right like it's just it's just it's just not the same exactly exactly there's 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 that's not to say that there aren't enthusiastic c++ core developers either right but um right some of those folks uh have been doing it for like 20 odd years and maybe maybe they want to change so 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 pooh-poohed them a little bit when we talked about java and they're 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 base type like java does like object but they do support a more generic system. So that doesn't make any sense at all. Again, so a generic system where you can have a container of something where the something isn't known at compile time, but yet the something is constrained. Now, in C++ world, 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 type can go in there and provided 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 can't make a list of those types that you just loaded in from a DLL or something like that. Because as we discussed, it requires running the compiler to generate something for them. A technique that sometimes is handwritten in C++

is called 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. You maybe need to be able to compare it object from one place to another or clone it 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 a sortable interface and um and any object that that can be adapted to provide a sortable yeah so in that case the the sortable interface and the sort function could be compiled and live in a binary somewhere exactly and your sort of third party code could reuse that exactly right in a generic 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 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 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 uh benefits and it's used internally in this in the stL in a couple of places. What Rust and what I'm more weak on Swift do is they allow for declaring this at the language level and letting the compiler essentially say, I can adapt your type to fit this interface because it provides all these things. 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. You're right. I'll take this object that you say, and it's got an implementation of this interface somewhere else. And I'll say, okay, 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 traits objects. These traits allow you to adapt any old chunk of data to any interface and that can be done at this time and that's kind of cool now it's it's and so right coming all the way back carbon is going to 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.

And now I can sort those things. And 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 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 like, and I will compile the sort function once and once only. And it will work with the interface.

And then I will adapt for the interface and make a generic that fits it. Again, I think in Rust it's called traits objects. In Swift they call them witness tables, I think. There's something like this against a little table that's like automatically generated that sort of bridges the gap glues a specific instance type to a generic interface type at the binary level now it's never going to 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 right 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'm going to 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 and maybe it is only used in places where I do know ahead of time what the actual concrete types are. So I can use the template-y generic system. Or no, actually, it's not performance critical. It's bloating my binary with 300 different copies of 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 because instead of laundering it through the base pointer that's an object 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 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 like, well, actually, I can't use my nice, shiny interface type anymore because it isn't performing enough. And now I'm going to have to like in order to have a test version and not a test version, I'm going to use a template.

And now I have to rewrite it. And I don't like it. It's nice just to change it around. So that's what I'm most excited about when it comes to carbon. But again, it's a long way off. No one listening to this should think that they can go off and build something with carbon. They can certainly go to Compiler Explorer and they can drop down carbon and they can see the assembly view isn't actually assembly view because there is no compiler. The assembly view will.

I was going to say, if there's just an interpreter. 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 like hey this can be substituted with this so i'm substituting that with this and so you mean this and steps and eventually obviously it starts actually executing the program is 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 parsing header files.

You can actually show that the interrupt in 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 code? And so I'm looking forward to that day. Are there any other like language features that you at least know about with carbon so the thing that keeps coming up on all of the the lists and certainly on the twitter twitterverse when it was first announced is carbon doesn't currently have support for strong memory safety so the 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 are references to them so no more dangling pointers um and um that's great you get a compiler error that says hey you pass this to this function which then took a reference to it and held on to it in like some local state variable and then it fell off the stack and that's an error right in c++ you compile it with all these sanitizers and at runtime it'll go oh maybe that happened and that's that's a terrible time to discover that kind of error so rust wins on on that front for certain. 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, when I first looked at Rust, there were occasions when the borrow checker was too stringent and couldn't prove there was no flow in which you escaped a function and it hadn't taken a reference to something in under certain situations but i believe nowadays it's a lot better so maybe maybe my sort of like um my experiences are gone but there are definitely situations where it's hard to prove like doubly linked lists i think is the classic example where you know every every pointer has a pointer back to the previous one and if it's a circularly doubly linked list it's like well what's the what's the life 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 not going to talk more but popping the stack carbon doesn't try to solve this problem, partly because C++ and its strong interoperability with C++ kind of makes that hard, right? Essentially, any call to C++ would be, quote, unsafe, given the Rust model, right? Again, if you're in Rust and you're calling out to a C API, it's unsafe by default. 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 so yeah the only things it can do is do you know makes makes some of the defaults like uninitialized variables so in c++ and c if you just go int i semicolon then that's got no value at all it's 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 has said well you've made a mistake there and you're not allowed to make mistakes so i'm going to take advantage of that and optimize it out in some crazy way so the dreaded undefined behavior but carbon has gone with like no we're going to 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 initialize this fine 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 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 design there is a desire to move towards a uh a safe subset 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 story right now and i think a lot of people are like what the heck you're inventing a new language here we are in 2022 and we're still going to have all of the overflow errors that we had and the use after free and the double free and the leak problems. 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.

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 sanitizers. So I'm not as concerned about that myself, personally, maybe just maybe, I'm in a luxurious position of like, none of my code has 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 tried to hack anything that I had on the internet

that was written in C++, then they would immediately discover all of the overflows that I haven't. So maybe I'm just blind to that. Does Carbon have its own standard library or is it just going to piggyback off the c++ library how's that going so my understanding now we're into a bit that 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 and have libraries that do more things than, say, the standard library does in C++.

I think that's always been another point of contention is like the STL is necessarily – no, not necessarily. The STL is relatively limited. 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 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 one range that's a that's a bounded sequence and another range 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 I'm hyperbolic here. And so why would we ever need to have a string.includes other string? Right, right. But to me, that's facile, right? 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's hard to find the balance. It is. But I think C++ really suffers from not having a lot of, like, what would be straightforward stuff. You know, like, hey, I want a 2D graphics library. I just want to draw pictures on the screen. I want to 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 do console out. That's it, right? Nothing else. And that's, you know, when you're trying to demo to folks, you know, stuff, it's just nice to be able to draw a Mandelbrot set in a couple of lines of code or stuff like that. But, you know, networking, there's no networking. It's coming soon to C++, but it still isn't there. And there's a lot of degrees of freedom in networking, of course, but it does seem silly you can't write a modern web server without pulling in hundreds and hundreds of bits of other things.

There's nothing there in the standard. So is Carbon going to have a calendar API, and more importantly, is it going to be called dating? Oh, the Carbon dating library. It's going to have to now. You heard it here first, folks. I mean, there have been a number of gags you could imagine about carbon. I mean, it's a whole new opportunity for puns with this language, right?

Like you just... 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 a good external name it's 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 medicine tactic variables especially as i've tried to move away from the the other ones that everyone uses Bob and Ian, they're just the two words. You know, they're my personal silly metasyntactic variables,

especially as I've tried to move away from the other ones that everyone uses, right, for various reasons. But I think probably still 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. I think it was some simulator of some exchange. It's like, it makes no sense. It's an agent that makes an exchange do something.

And I'll just call it Bob for now with one of the intern type folks. And I'm like, yeah, well, that's what it is now. Yeah, Bob forever. 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 for when they launched. And I'm really interested in seeing where it goes. Yeah, yeah. Okay. Well, is there like an upcoming inflection point for Carbon? A date that we should be looking out for or a release or

something like that 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 so there's a lot of documentation aspirational and 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 but that's a whole other conversation and there is a discord that you can join again there's a very strongly enforced and carefully set out code of conduct with 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 in its early in its early infancy uh if you if you sign the cla there's a 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 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 Carbon was coming in the pipeline because of Compiler Explorer have now joined and are involved in that so I'm excited to see that kind of synergy of folks that I know are very

interesting and interested in this joining so come along and join. Yeah, it sounds super cool. looking forward to see what happens with it all right well um until next time i guess until next time you've been listening to two's compliment a programming podcast by ben rady and matt godwald find the show transcript and notes at twoscompliment.org. Contact us on Twitter at twoscp. That's at T-W-O-S-C-P.

Theme music by Inverse Phase. Inversephase.com.