C++ Club - Carbon

Episode Date: August 7, 2022

With Bjarne Stroustrup, Gianluca Delfino, Vladimír Arnošt, and other colleagues. We discuss the Carbon programming language from Google.Video: https://youtu.be/-kh2gbjN48gNotes: https://cppclub.uk/meetings/2022/152/

Welcome to C++ Club. This is meeting 152 that took place on the 4th of August 2022. As a prelude to the main topic, we are going to briefly discuss this article posted on the Google Security Team blog. It's called Retrofitting Temporal Memory Safety on C++. It's an article on their progress. They talk about temporal safety improvements which mitigate use after free errors as opposed to spatial safety which is about dealing with out of range access like buffer overflows. So the current state-of-the-art ways of for ensuring temporal safety are static analysis which doesn't see all errors sanitizers which slow down program execution significantly smart pointers you should use them and also Chrome has

a garbage collector called oil pan but that changes C++ semantics. And there is also the class called miracle-pointer, which ensures deterministic crash on dangling pointer access. The new mitigations discussed in the article are memory quarantine, heap scanning and memory tagging. By the way, when I read this I noticed that they don't mention the core guidelines and the memory safety and safety against use after delete that's implemented there. Yeah, they have their own guidelines that they follow, which sort of makes their C++ a bit non-standard.

The memory quarantine is explained as follows. The basic idea is to put explicitly freed memory into quarantine and only make it available when a certain safety condition is reached. The main idea behind assuring temporal safety with quarantining and heap scanning is to avoid reusing memory until it has been proven that there are no more dangling pointers referring to it. To avoid changing C++ user code or its semantics, the memory allocator providing new and delete is intercepted. Upon invoking delete, the memory is actually put in a quarantine where it's unavailable for being reused for subsequent new calls by the application. At some point, a heap scan is triggered which scans the whole heap, much like a garbage collector, to find references to quarantined memory blocks.

Blocks that have no incoming references from the regular application memory are transferred back to the allocator, when they can be reused for subsequent allocations. So this is sort of like a garbage collector but not really as you still have to manage memory manually. Who invokes this scanning? Does it trigger by itself somehow magically? It's yeah it's like runtime or whatever thread is doing that in chrome. There is some sort of setting that states you know once you add something this dimension then you're gonna have to scan or something so maybe there is some customization you can do but eventually you're gonna pay the price for this sometime in the code yeah there are several versions of these memory scanning algorithms collectively called star scan or asterisk scan literal asterisk scan, literal asterisk character. Try googling that.

There is a small problem. When used in Chrome, StarScan slows it down by 12%. So hardware memory tagging comes to the rescue here. It's a new extension of ARM architecture to help detect spatial or temporal memory errors. This is how it works. Every 16 bytes of memory are assigned a 4-bit tag. Pointers are also assigned a 4-bit tag. The allocator is responsible for returning a pointer with the same tag as the

allocated memory. The load and store instructions verify that the pointer and memory tags match. In case the tags of the memory verify that the pointer and memory tags match. In case the tags of the memory location and the pointer do not match, a hardware exception is raised. Combined with star scan, memory tagging lowers the performance regression to just 1%. So these are the latest memory error mitigations from Google. But they seem to be oriented towards fixing memory errors in code that uses new and delete, which are discouraged in modern C++. We've had smart pointers since C++ 11. Well, auto PTR doesn't count. I'm sure this is a simplistic view of things, and I know all the details of course,

but what if, and bear with me here, Google used smart pointers in their C++ codebase instead of coming up with elaborate ways to fix C-like C++ code? This mitigation would still trigger even if you use smart pointers because they would still intercept the underlying call to new and to delete, so... Yeah, but they would alleviate the dangling i mean yeah that would be wasteful i think you know you'll be using a smart pointer so you wouldn't need this but i think this will still get triggered because they they intercepted call to new will still be called and you still have this underlying magic, maybe mitigated by this hardware, also magic that you mentioned, but still.

Yeah, yeah. So here's a quote from a tweet by Titus Winters. There's a load bearing 10 billions of lines of code in C++, and it can't be usefully improved. As the next item will demonstrate, improving the existing C++ codebase is not an acceptable solution to Google. What they chose to do instead was to create an entire new language. Enter Carbon. The new experimental language Carbon was unveiled by Chandler Carruth in his CPP North conference talk. I think it's a terrible name for a language.

Google couldn't choose a name that you can actually google? Oh wait, I know, it's a pun in itself. A play on C, the language. Which is also the chemical symbol for carbon. It's so clever it overflows and becomes stupid. I agree with that, yes. I hope there wasn't a reasoning, but it's entirely possible. Also apparently carbon, in the context of software, is trademarked by Apple.

Apple Carbon is the name of a legacy macOS application programming interface. Maybe they plan to change also the name, given that the ethos of the language is just, let's break it every once in a while. Yeah, quite possible. They would call it barbon next time. Yeah, why not? So I watched a talk by Chandler, and here are some quotes from it. Quote, C++ is not doing as well as we would like.

C++ is very unsafe. End quote. So what is the root cause for C++ falling very unsafe." So what is the root cause for C++ falling short of its goals? Quote, accumulated decades of technical debt and prioritizing backwards compatibility. End quote. I know where this is going. ABI and backwards compatibility. Quote, backwards compatibility prevents us from

fixing technical debt. This is not a recipe for success. C++ evolution process makes improvements even more difficult. And they have a whole document on their website called difficulties improving C++. Chandler says that's why C++ has failed. Has it though? What he really is implying is C++ has failed Google and Carbon is an answer to that? It has failed Google according to some people at Google. I have not been able to determine whether Carbon is

going to become a Google language or a language promoted by some people at Google. It's not the same thing. Yes. Yes. Yes, that's right. There are teams at Google that are not involved in this in any way.

So it doesn't seem like an official Google move. It's just a certain team that is doing this as an experimental. So Carbon is an experimental successor to C++, and the main design goals for it are C++ interoperability. That's like the ultimate goal. The next one is migration support, so that any code base in C++ would be able to migrate to Carbon incrementally. And language evolution, which means tool-based upgrades as Carbon improves.

Specifically, no backwards compatibility or stable ABI. Carbon tries to make parsing code simpler as well by adding more syntax. For example, these keywords act as introducers and you can see them in some of the screenshots with examples on Google's GitHub. fn introduces functions, var introduces variables, and let introduces constants. Hi Scala! The if statement is actually an expression, like in Scala. Or maybe also in Rust, I'm not sure. There are no references, just pointers. Output parameters of functions are pointers with a fancy new syntax which are non-nullable and non-incrementable. Interestingly the current Google C++ style guide requires

using non-coincident pointers, not references for output parameters. There is also an explicit object parameter for class methods. There is also an explicit object parameter for class methods. Yeah, they are called methods, not member functions. Which is sort of like deducing this in C++, which can be prefixed with the keyword adder to become mutable. It's totally intuitive. Files define namespaces via packages, and there is no global namespace. Members of a class are public by default.

This is copied from Kotlin. And they can be declared private by using the keyword private before each of them. There is single inheritance only, and classes are final by default. You can use base prefix to enable inheriting from a class. There are generics with definition checking, like the initial C++ OX concepts proposal. They are defined using the keyword interface. Fewer virtual functions are marked with the abstract keyword. If you define an interface you can then implement it and then accept it in a function. With checking you have to explicitly opt into an interface.

This also enables extending classes you don't own, like extension points. There is no ADL in Carbon. To prevent ODR violations, class extensions can only come from the original class or the interface declarations. I'm personally disappointed at the missed opportunity to adopt colon=" as an assignment operator. The Carbon designers seem to love syntax. I hope they provide a pronunciation guide for it. Chandler admitted that C++ is going to be here for a very long time, therefore the most important point is C++ interoperability. You can import C++ headers for header files with a statement import cpp, where c is uppercase and PP is lowercase. Weird. Library and then the name of the header file. And that synthesizes a matching carbon AST

by using C++ frontend like Clang, which is then imported into Carbon. All the tooling for Carbon is currently based on Clang, by the way, but they say it's not mandatory and in the future other toolchains might be able to support Carbon. They will probably decide all the new directions, I think. So, I mean, other people can also implement tool chains, I guess, but this is Google technology, right? So if they want to change it, there's no other process than they want to. Maybe you can submit a request, but if they don't like it, I guess they are not going to approve it. Yes.

The other way around is when C++ imports a carbon package as a header file with a statement hash include, say foo.carbon.h, and treats the content of that package as a namespace foo. This is based on the old Clang modules, not the new C++ modules. It also reminds me of how Swift and Objective-C interop works. Probably they used that for their inspiration. Come to think of it, how will this work with C++20 modules, you know, the proper ones? They haven't mentioned anything towards that i think there's still a lot to be decided i guess there's a lot they haven't decided yet that keeps being here so well

to work in the future people can imagine that will work and it might but i do note that their modules are not C++ modules. Their concepts are not C++ concepts, and they don't yet have routines. This looks very odd to me. So how are they going to integrate the new modules once everybody in C++ will use the new C++ modules, they will have to support those and their modules? Is this interoperability with C++ going to become a problem for them eventually? Are they going to break entirely? Only time will tell, I guess. Yeah. Or they may kill it.

One question would be how much can you interoperate? Which subsets of each language can interoperate with which subset of the other language? Because they are definitely different languages. Finally Chandler explained what the carbon language process was going to be. It's not ISO but a community process including GitHub, Discord and other modern collaboration tools similar to Swift I'm guessing. The license is LLVM. The language evolution process will be based on GitHub pull requests. For bigger decisions, there is a governance process headed by Chandler Carruth, Kate Gregory and Richard Smith. So yeah, like you said Gianluca, they are free to reject any pull requests that they don't like. We have to hope that they are not evil.

As we have been hoping. That ship has sailed a long time ago. They even removed it from the official website. Yeah, indeed. Back to Carbon. Batteries included. Everything is provided out of the box, including tools, ecosystem, package manager, eventually, etc. The build system is Bazel. I like this quote by Oliver Smith on Twitter.

Looks at Carbon. Sees Bazel. Deletes search history. Throws computer out of the window. Speaking from experience, I guess. The slide in the presentation with the current contributors to Carbon had some notable names in it, including Kate Gregory, David Senkel, Chandler Carruth, Daisy Holman, Hanna Dusikova, Matt Goldbolt, and Richard Smith. Companies and organizations involved so far are Google, Adobe, and Indiana University. There were some live examples of Carbon code using VS Code as NIDE. Also, Compiler Explorer supports Carbon already.

In the Q&A session, the following statements were made. There is no meta-programming or reflection story for Carbon at the moment. There will be an independent foundation for developing Carbon, but at the moment it's governed by Google Contributor License Agreement, which is a showstopper for many people. Inspiration was drawn from Rust, Zig, Haskell, Kotlin, and also Swift. Swift was used for generics, I think. Carbon will have no fixed library ABI. When you build a carbon program, you build everything, just like Google does now. No surprise. There will be a way to define a stable ABI on the boundary, which is a rare case, as Richard Smith said. Source compatibility will be handled by tooling.

Richard Smith said, a really easy way of migration. There may be some amount of versioning or Ebox even. I personally get worried when I hear the words really easy in a context like this. Build system will not be necessarily Bazel. That's a relief. For C++ Interop, C++17 is the baseline. But obviously that may move with time. There will be no support for old hardware architectures. So people were guessing that 32-bit architectures are out, which could mean that 32-bit controllers will not support carbon. Governance, there will be rotations of the three benevolent dictators.

The goal is to end up with a bench of people who have been a lead, according to Chandler Cruz. It will be a layered consensus model with tiers of escalation, like small groups. This sounds like a committee with working groups. Carbon will be willing to break old code. In my opinion, this is actually pretty inconvenient, as I experienced it with Swift until it finally reached source stability. The migration tools sucked. Source stability is good. It's unclear what the change rate will be and the users will be able to influence the process. Hmm, how about 3 years? As little undefined behavior as possible, but there will be C++ boundary with potential UB. Richard Smith says, if there is UB, we will provide you with the ability to check for it.

I'd like to see how they do that, as we previously discussed an article by Chris Lattner, who demonstrated that diagnosing UBE is a really hard problem. Especially given that they don't want to go all the way like Rust to specify the lifetimes of everything. They want to have something in the middle between C++ and Rust but not commit all the way. So you'll still be able to do a lot of the undefined behavior that you can with c plus plus and they probably slap on sanitizers as usual i guess yeah i i have sort of refused to comment on carbon because it's simply too unspecified or underspecified to make a technical comment on and I'm going to stick to this in any detail technical comments so just premature as I suspect the language is if I tried to release

something like this from AT&T and ASUS C++ I would have been also politely told to get it working first. I wonder how much that is also kind of by design. If they keep it vague, then everybody kind of can read whatever they want into this. That's right. People always assume that once things are fixed, it will be fixed in the way they imagine it should be fixed. And they will imagine that no serious problems will be found during the process. So it's obvious that if you have a much smaller group of people controlling and contributing, it's much easier to, well, control. The problem with the current C++ committee is it's much easier to, well, control. The problem with

the current C++ committee is it's so darn popular. We have hundreds of people who want to help. That is a problem indeed. How do you go about trimming? Maybe that's another topic for another day, but how do you go about

trimming that? You can't trim because one of the rulers of anything political to anything that has no date political is that people don't give up power they've got and so to tell a nation or a company or an individual that, you can no longer vote. We have some stable group of dictators that will decide whether your ideas are good enough and whether your ideas are worth doing right now. This is not going to happen.

This is just not the way an organization can work. It's the way a corporation can work. It's the advantage of a corporation or a dictatorship. I do not know how to solve this problem in the context of WT21 and ISO rules. It is very, very difficult and you end up having to talk, talk, talk and convince a lot of people. What if the people who are now interested in carbon and not interested in particular in advancing C++ anymore, or became disillusioned by the ISO process and the committee, leave

to work on carbon, and by doing that indirectly improve C++ process? I have heard that suggestion, but I think the net effect will be that energy and resources will leave the C++ community, just as it happens when Sun pushed Java and started hiring good C++ people because they knew how to build systems. So Carbon will try and recruit good C++ people because well, they can build things. And the net effect on C++ is I think more likely to be negative than positive even though there are people who have suggested it. I guess we're going to end up in, potentially we may end up in a fragmented situation where some vocal members of the C++ community that overall were

driving things forwards will now move or will be tempted to move to to carbon in a way and so some people may want to instead of focusing on C++ as students, maybe they would want to try Carbon. Carbon or Go or Rust or Swift or Bell or one of the other couple of dozen languages that wants to take on C++. C++ has a big target on its back and everybody wants to do do serious systems work has to be the next seat of us. And so this goes through the territory. Interestingly, exceptions were not mentioned in the talk at all, and nobody asked about them during Q&A.

I asked Chan to talk to him. He said there wasn't any just yet, but it wasn't decided. Right. At least Chandler doesn't consider exceptions evil as such. Oh, that's a really... We will see. Well, that doesn't mean... Well, it doesn't mean anything.

It's undecided i wonder if they would at least move towards more like static uh herbceptions kind of design because they wouldn't uh in google they they don't use the normal exceptions already yeah uh this google was deep deep into undisciplined use of fighters before they discovered c plus plus so it existed they for for years they didn't allow any form of this sort of confirms my suspicion that google positions carbon as a successor to the google's flavor of c plus plus where exceptions are already prohibited. But maybe... We will see. It is too early to make strong statements about carbon. At least, it is too early for me to make strong statements about carbon. Come to think of it, there wasn't any mention of carbon error handling at all.

Peter Dymoov tweets, presumably quoting CarbonDocs, for now, carbon does not have language features dedicated to error handling, but we would consider adding some in the future. End quote. To which Viktor Zverovich predictably replies, carbon developers simply write code that always succeeds. And more from Victor.

Breaking. The C++ committee threatens to add new features faster than Carbon is able to support them. Doug Greger tweeted. It's a subtweet. Just to remind you, a subtweet is sort of a passive-aggressive reference to something you don't mention directly. Quote, I don't think any programming language unveiled in 2022 should lack memory safety. We have to move on from the it must be as fast as unsafe C mindset, because the engineering cost of unsafe by default is so very high, nice syntax and

whiz-bang features don't make up for it. It takes an enormous amount of effort to bring a new language into the world and make it useful, to port code, reimplement core libraries. If you aren't getting safety out of it, why incur that cost? Is the end result actually better or just more pretty? I know a thing or two about programming language design and trade-offs. I'm saying that not making a new language memory safe by default is to me a critical error that you cannot recover from once you have users." And to remind you, Doug Greger helped create Swift. Wilia Wotilainen, regarding Carbon Generic Concepts interfaces tweeted I'd be really interested to see how you write generic duck type glue functions that take two arbitrary types without opting in to either.

That is, if that's possible. And the puns, oh the puns. Viktor Zverovich again. If you write spaghetti code in Carbon, do you get Carbonara? Marius Bonchilla replies, if you copy-paste code in Carbon, do you get Carbon copies? On a more serious note, there are some quotes from Reddit, which has even two threads discussing Carbon, and also some Hacker News quotes. Jonathan Muller, quote,

To give some context, in February of 2020, there was a crucial vote in the C++ Standard Committee about breaking ABI compatibility in favor of performance, mostly pushed by Google employees. The vote failed. Consequently, many Googlers have stopped participating in the standardization of C++, resigned from their official roles in the committee, and development of Clang has considerably slowed down. Now they've revealed that they've been working on a successor language to C++. This is really something that should be taken seriously." End quote. A reply to that goes, counterpoint.

No, Google is one of, if not the worst, maintainer of languages there is. Their methodology is exactly what you see here, our way or the highway. Their documentation is snarky, where they insist some hacky way of doing something is the right way to do it. It is always written in a condescending manner. Their developer resources are insulated from critique and criticism, where they are in charge, and if you disagree, too bad. Let them do their thing and take their toys and play in their sandbox at home, away from anybody. They won't have to share, but they'll get bored with it and kill it in two years anyhow.

This is based on the contributor's experience with Go and how it was handled by Google. Somebody mailed me a link to the Google graveyard. Yes, I was going to mention that. It's good. So this poster says, I don't want to imply anything, but coming up with a new language after losing a vote about a standardized language is a bit like an angry child throwing a tantrum transposed to the giant tech company world. A reply to that was, The sentiment is blatantly uncharitable. If anything, it's difficult to understate the importance of C++ at Google.

They didn't spend billions upon billions writing hundreds of millions of lines of C++, only to throw it all away over a few rejected proposals. Indeed, it's one thing to lose a vote on a proposal, but it's another thing to lose faith in the standardization process, as Google has. There was a another very long and detailed comment that I'm not going to cite, because it's so long, but it's very insightful and interesting, so go and read it, I'll be linking to it in the show notes. Jonathan Muller responds on Twitter. To countless people in the Reddit comment section. No, somebody implementing their own language after they've failed to change an existing one

isn't throwing a tantrum. Programming languages are tools. If they don't work for you, switch. If no alternative exists, invent one. My take on it is that, like Yubiana said earlier, one outcome of the Carbon project which is already happening is that some very notable people who used to work on advancing C++ so C++ may lose. But we'll see how this plays out. And to mention this sad website, the fact that Google is behind Carbon also suggests that there is a non-zero possibility the entire project will be abandoned in a

few years. And this is killed by Google website, which has many good things that are no more. Enough time has passed since the initial announcement that hot takes and reaction videos started to appear. TechRadar posted an article titled Google thinks its new programming language can topple C++ and so did 9to5 Google website. I suggest you watch this short video clip by CodeReport which is Connor Hexter called Carbon Language the

C++ Killer and I thought the video was very good and very funny. Another video is a first impressions video from the creator of Odin programming language. And no, I haven't heard of that one either before. A recent reddit post titled What is ABI and why did Google create their own language for it? has many links on ABI, including articles and videos. Bryce Lelbach and Connor Hextra have a podcast together called Algorithms plus Data Structures equals Programs in short ADSP

and they had an entire episode talking about carbon some quotes from the episode Bryce says carbon evolution process is drastically 10 times better than the C++ ISO evolution process, which is rather dated. Bryce is much more optimistic about the future of carbon and rust because of that, than the

future of C++. this is the person that wants to be in charge of C++ evolution. He said he hopes that... And the person that has attacked ISO in public. He said he hopes that the C++ processor can be fixed in the future to not be tied to ISO. In other words, C++ leaving ISO. In other words, C++ leaving ISO. Connor says, why not just make C++ better? Bryce replies, people who created Carbon spent a decade trying to make C++ better, and it didn't work out. End quote. Didn't work out for them? It's a bit of a weird statement,

to be honest. Is he saying there was no progress in C++ for the last 10 years? He names other people, Doug Greger, Dave Abrahams, who tried to make C++ better, but then departed to make other languages notably Swift. Dave Abrahams is back to C++, but Bryce says he is not involved in the committee, at the moment at, but Bryce says he's not involved in the committee, at the moment, at least. Bryce says, we should be willing to breaking changes to fix mistakes, end quote.

And not only because of performance considerations, but also to fix things like defaults. And Connor... It's very hard to get agreement. Some mistake. And even when you agree, it's very difficult to know how many millions of billions of lines of code depends on that stick. the fundamental problems that any successful language has to face and any novel language with few users don't have to face unless it gets successful. Connor talked about fixing C++ defaults. All those constexpr and nodiscard we have to add because they weren't available when the defaults were decided. Bryce said that Carbon doesn't

have to get the defaults right because they will be able to fix them later by breaking things. So then when you are looking at Carbon code you have to know its version or revision in order to understand what is implied because the defaults will change between versions? Will there be a way to specify which version of carbon is used in a particular file? How will the upgrade tooling deal with it? Will it be possible to combine carbon versions in a single program? I think it's going to be called carbon dating. Excellent.

So yeah, looks like Bryce is super enthusiastic about carbon, and only time will tell how this will affect his involvement in C++. Bryce refers to the CPP North keynote by Sean Parent, titled The Tragedy of C++. There is no video available yet, but some quotes are, What makes a tragedy a tragedy? It requires the protagonist to be successful, or the story is simply tragic and not a tragedy. C++ is successful. In Act 1, we explored the reasons why C++ is successful in introducing our character. In Act 2, we looked at how some of the very strengths of C++ can also be very damaging. Jonathan Miller posted an article on his blog on carbon's function parameter passing titled carbon most exciting feature is its calling convention. Quote, by default if you don't write anything else carbon parameters are passed by the equivalent of a constref in C++. However, and this is the important part, the compiler is allowed to convert that to a T,

to a value, under the as-if rule. Jonathan claims that the carbon compiler will do the right thing so that you don't have to think about it, selecting the best way to pass a concrete type. C++ can also optimize the Y-accon's references and replace them with values, but apparently this creates a copy, whereas in Carbon it doesn't. I'm not sure how this works with primitive types though. He says that in Carbon the value is simply set into a register. For primitive types it's a copy, isn't it? I think the idea is that the language will be able to decide whether the object is small enough to fit into a register and then just shove it into registers if you can.

Whereas in C++, there is ABI reasons why you cannot, in cases where, for instance, there is an untriggered destructor, you cannot put things that would fit into register. You cannot just pass them in registers anyway. And the claim here, and so correctly, is that given that they can break ABI, they can actually put things that fit into register and improving performance. That is what I get at here. Yeah, yeah. Jonathan says that C++ optimization is limited because function signature is part of ABI, but in Carbon we don't care about that, of course. Another advantage that Jonathan is especially excited about is that in Carbon, you can't get address of a parameter unless it's specially annotated.

When you can't take a parameter address, the compiler can avoid escape analysis. Parameters can't be indirectly and unexpectedly modified in the function. Jonathan really dislikes C++ references. In the Reddit thread, he said, quote, References are misfeatures. The language is better off without them. For example, const ref parameters are unnecessary. It's the default. He clarifies further, quote, References were added to C++ to allow operator of loading that return L values like indexing. Given that by design

they act like aliases to other objects, they are problematic to generic code. See optional off reference. And heavily complicate the type system. There is a lot of complexity in C++ solely because of reference types. If references did not exist and a few use cases where they're really useful replaced with different features, returning L values from functions, parameter passing, lifetime extension, range 4, C++ would be a lot simpler. It wouldn't be a C++ though, would it? In the same reply, he also said of Carbon concepts, quote, the language has concepts and the far superior C++ or X version, not the stripped down sugar for Sphenei we've gotten in 20, end quote.

He seems to be very polite, doesn't he? We are witnessing a lot of venting about c plus plus aren't we i think there's a lot of pent-up emotions here you know since that original cpp talk about the unique pointer not being able to be passed in register i think that's that's this the the initial seed of all of these which then led to the the suggestions to fix that problem which never taken serious by the people who that criticism it's the abr it's doing it yeah actually unique pointer can be passed in the register. It's just a pointer in a structure. So if you pass it by a value, you move it all the time, it goes in a register.

Yeah, but that's not what the ABI says. It depends what you put in your ABI. If I remember correctly, you can pass a structure that is trivial in registers. But you cannot pass a structure that is non-trivial that is for instance you know a non-trivial destructor you cannot pass that in a register and that's abi specification all right tristan brindle had some feedback on Twitter. Quote, I think this could actually be good for C++.

Carbon can move fast, innovate, and make mistakes that can be corrected. The successful ideas can be backported to C++ in a compatible way without the pressure of having to get it right first time. It's like C++ Playground of sorts. Continuing his quote, as to the language itself, signature-based checked generics are clearly the way forward. As an aside, it's interesting that Swift, Rust, and now Carbon have all converged on a generics model very close to C++ OX concepts, a validation of Doug Greger's ideas. What we could have had? The memory safety story, we'll figure that later, is a concern. Likewise, error handling. It seems

like exceptions will be necessary for C++ interop, but will they be idiomatic in Carbon, or will it be monadic error types like other modern languages? Or something similar to Herbceptions? Syntax quibbles, mandatory semicolons seem dreadfully old-fashioned in a language designed in 2022. I like this guy's optimism, but I think if it was possible to back part any of the improvements to C++, probably those improvements would have been done already in C++. Yeah. Yeah, I agree.

I like the quote that the three year update cycle is too slow for half of the C++ users. I don't know how you defend that half, but it's certainly too fast for the other half. And we don't know what the half refers to. Half of people on Reddit or half of people

who develop stuff and don't post. Half of people who post on Reddit, probably. There is an unofficial Carbon subreddit, you can go check it out. And recruiters, don't waste any time. Not sure if this is real, but this tweet shows a photo of a job posting which requires 10 years of Carbon experience. No exceptions and C++ doesn't count. Yeah, so...

I think we'll end up on this today and I'm sure we'll discuss Carbon later despite the fact that this is called CppClub because it's related to C++ anyway and I will leave you with this excellent post by Amir Kash. It's a photo of several fast food customers fighting each other and the other guy just sitting there eating his food looking at his phone. The fighting people are labeled Nim, Carbon, Go, and Rust, and the guy eating his food is labeled C++. Right. Thank you very much for joining, and we'll continue that next time.

Bye. Cheers. Bye.