Carbon Language Successor Strategy: From C++ Interop to Memory Safety - Chandler Carruth - CppNow 23

[@ddevienne]

The clarity of the delivery, and the depth of thought / research it shows, is really impressive.

[@gregandark8571]

Chandler Carruth = 100% QUALITY GUARANTEE!!!

[@RD-fb6ei]

It’s great that carbon looks like you get the additional features from rust while keeping the power of C++.

[@DarenC]

I haven't used C++ since 1998, but this was most interesting and excellently delivered!

[@cinamynj]

I’ve never touched code before, but these Carbon / C++ talks are so interesting to me

[@_____case]

What are your key takeaways? I'm curious why this has meaning to you when it's so deeply technical.

[@CuriousCauliflowerX]

Great insigths on escaping the pit of despair that is C++ code which no language can acutally interop with. This could in principle be adopted by many languages that want to interop with C++, thus letting many C++ programmers escape their misery.

[@TheFriendlyInvader]

Misery? Shit I'm miserable when I work with most things that aren't C or C++ -_-

[@isitanos]

Very good talk. I'm more interested in Carbon now that I see that you have very good in-depth understanding of the tradeoffs you picked. Having a plan for C++ migration (not only interop) from the get-go is very interesting too, especially since it should allow you to bootstrap your own standard library by using C++'s. Importantly, I think that keeping some kind of transpiling/2-step compilation that goes through C++ would be important to provide a migration path for projects that are multi-platform and multi-compiler, notably AAA games. I don't think Sony lets you use anything else on PS5 than their fork of Clang. Microsoft does give you the choice between MSVC and Clang so I assume the Carbon toolchain would fit right in.

[@ChandlerCarruth]

We think we can avoid the 2-step compilation, and that doing so will be important to hit the key performance metrics. Fortunately, Clang has production quality support across the platforms. Both Firefox and Chrome ship compiled with clang on Windows. For platforms with super tight lock-down of a toolchain like game consoles -- if they're Clang-based, we're likely to try and build ways to use that fork of Clang as the Clang-part of Carbon. And if not, we'll eventually go down the 2-step process and synthesize C++ code we feed to their toolchain.

[@0LoneTech]

So, Zig-style interop, Kotlin-style language cleanup for idiomatic C++ code, with some inspiration via Rust (which isn't really new, C++ tradition is to bake in everything somewhere with terrible naming). This has potential, but still looks noisy just to feel at home for C++ers. I wonder if it'll get another cleanup, Coffeescript style. Perhaps notable, D already did bidirectional interop with C++ but didn't include templates (added to C++ a decade earlier), and templates became critical. C++ remains a moving target, but now it's changing faster in the template library than language level.

[@seasong7655]

true, similar to python as well

[@brenogi]

Did Carbon introduce "unwanted" features to be able to seamlessly interop with C++? If yes, would it make sense to have a 'extern "C++"' block and allow these features to exist only within this block?

[@skadragon]

What we will have to wait and see is if Carbon actually can achieve seamless C++ Interop. If we have both Carbon and CppFront offering a modern language and seamless C++ the future will be very exciting.

[@HellCatLeMaudit]

"You had to have seamless access to the entire software ecosystem ..." This. This is what Rust forgot. C++ became the successor to C because it was (and is still able) to access the entire C ecosystem. If any language is to succeed C++, it should be able to access the C++ ecosystem right now. Any experienced software engineer worth his title knows this. There is nothing more frustrating than being able to run "Hello World" in a new language and then realize that it's unusable for you because it doesn't have a rock solid cryptographic library that you need, or access to a graphic engine running on multiple GPUs, or, God Forbid, an inability to access that mission-critical proprietary C++ library your company has built because the supposed successor language insists on turning its back on the entire C++ ecosystem because it is "too complicated" and "obsolete".

[@aDifferentJT]

I don’t think Rust forgot, I just don’t think Rust was aiming to be a C++ successor, more like a C++ alternative.

[@TheFriendlyInvader]

​​@@aDifferentJTRust was aiming to be a failure out the gate with an antithetical design goal. You can't have safety in embedded/low-level environments, you can have safety as an *option* but you cannot have it universally. Critically upon realizing that you find out that C and C++ already have utilities to enforce safety at compile time. Which makes it questionable as to why you would migrate at all.

[@J.D-g8.1]

I havent tried rust yet, but thought, or expected, since its both "new" and "low level/supposed to be good for reaching the hardware" that it would naturally be easy to call c++ from it. If it isnt, i dont really see why it would have any appeal of for microcontroller programming at all. Might as well use micropython or lua or some other scripting language for non performant code.

[@umber-light]

@@TheFriendlyInvader The issue here is not in ability, it's totally possible to write safe C++ code, but it's not a *default*. C++ standard library and the language itself do not encourage and are not designed to write safe code free of memory bugs. Having a language which puts memory safety as a *default* option, will push more people to write more safe code over time and overall increase the amount of safe code on the planet Earth. Which is itself a big win.

​@@TheFriendlyInvaderRust has safety as an option, the default one. It works in embedded too. Not everything "safe" is inefficient or bloated (in Rust).

[@jules-bertholet]

At 1:13:42 it's alleged that the Rust code on screen is unsound, but it is perfectly sound! Miri reports no UB, and it doesn't expose any safe APIs that can be used by other safe code to trigger UB.

[@whydoineedausername1386]

It's absolutely UB, you have multiple aliasing ways of accessing v. You need to wrap the unsafe in a function so that the borrow taken by the pointer creation still applies to the resulting slices. Miri doesn't have any false positives, but it absolutely has false negatives

[@driedurchin]

I'm wondering what the "synthesized" API would like from an auto-complete perspective. If I'm in my IDE calling a C++ function from carbon, where will "go to definition" take me? If I'm debugging and "step into" will I end up in some weird middle land? I know in Kotlin you get a sort of "fake" Kotlin signature to complete against.

[@ChandlerCarruth]

Our (very, very tentative) plan is to have an integrated language server for both Carbon *and* C++ so that it can smoothly direct the editor to the underlying C++ code.

[@driedurchin]

@@ChandlerCarruth awesome, seems sensible. What about debugging?

[@ChandlerCarruth]

@@driedurchin Complicated. I think we're going to need to pursue maybe two independent approaches. Early on, we need to embrace the reality that the debuggers people will have won't support Carbon. We should emit synthetic debug information that let's people single-step usefully through the code, and provides some non-Carbon low-level access to types, data structures, and functions. For example, maybe emit DWARF to emulate an inlined C wrapper around whatever Carbon construct you want to access. This should enable most of the last-resort use cases and the most basic single-step use cases without needing any special support. It won't have the full ergonomics of the language, but that's probably OK. Where it fails, it'll be predictable and understandable. My guess is this will feel a lot like debugging C++ in WinDBG or old debuggers that had limited or no support and you would manually bridge from a C-ish syntax to access C++ constructs. But eventually, we should work to have a high-fidelity Carbon debugging experience. That'll need a good model for integrating a bunch of layers (dubugger, frontend, etc) that I don't think any debuggers today really have, so I think it'll be a much later phase. Ironically, I suspect the early version to actually work really well in an IDE context where you're not doing as much language-expression-evaluation, and the IDE can map from the source code in the UI to whatever C-based debug info access paths we provide.

[@driedurchin]

@@ChandlerCarruth Fascinating, that's pretty expected that it is complicated. Happy to hear there's at least a rough plan. Thanks for both the detailed responses!

[@Alperic27]

Only one issue… .. google’s uncanny habit of dropping things overnight…. .. so carbon will die, the question is when. But the bit on ‘long term play’ is a cool joke though 😀

[@ChandlerCarruth]

It's already 100% open source and anyone will be able to continue driving this if Google loses interest. We've also publicly stated that our plan is to create an independent foundation to drive the project long term. The goal is to follow the successful models of LLVM, Kubernetes, and others that are robust communities beyond any one company. We're committed to following through on that and ensuring the project is independent.

[@Alperic27]

been thinking about the whole thing recently: imho carbon should not be presented as a “c++ successor” … it is just a “new language” like there are many coming out every day.. with strong(complete?) c++ interop… focussing on c++ seems like a marketing tool to help free publicity. I have a lot more respect for swift that first built Swift with its own personality and flavor, and THEN started advertising that it would add a very strong interop story

[@RedFireDragonKing]

If we have to go from C++ to Carbon to Better Carbon -- how is that better than going from C++ to better C++? Both require refactoring efforts, but going to Carbon additionally requires retraining software engineers and seems to generally have a higher cost associated with it.

[@ChandlerCarruth]

Because introducing the core infrastructure and facilities needed for "Better Carbon" requires significant changes to the language and library, including breaking changes. We need to first get onto a platform that can sustainably make those kinds of changes, and C++ IMO currently isn't in a position to do that.

[@sqlexp]

It seems that the only selling point of Carbon is the borrow checker. That's just too pathetic. It has no reason to exist.

[@NotherPleb]

Actually promising solution to carry on C++ legacy, however I'm afraid it's coming late to the party and when Carbon releases people already moved on from C++, therefore the interop is no longer as valuable.

[@alskidan]

Wait. Does this title mean that we already getting a successor language for Carbon? 😱

[@Vitorian]

Aaaaaaaaand what do we gain here? "Safety"? When 99% of all datacenter machines run with mitigations turned off? This is a wild goose chase.

[@sweetcapitan5690]

As always, all the beautiful screenshots from the first presentations turned out to be bait, but in reality Google is providing us with another ugly language for its internal kitchen, which everyone will start using in their work because “after all, Google uses it.” We continue to write in C++ and study Rust, we were deceived.

[@4otko999]

i don't think carbon is the way forward. it seems to be borrowing from rust therefore making software unmaintanable. you need to write entire book about swap before you swap. looks more like an intermediate step towards migration to rust. val seems to be more readable, maintainable and generally productive programming language that doesn't make your life miserable. hopefully they will deliver on c++ interoperability. thanks for the headsup though.

[@ChandlerCarruth]

FWIW, we're looking *super* closely at Val -- now Hylo -- for how to make the safe subset as friendly as possible. We're very willing to have something further away from Rust. Even the generics infrastructure we've built, while with some inspiration from Rust, works hard to be different in ways we think will make it more usable or friendly.

[@4otko999]

@@ChandlerCarruthhonestly i would appreciate anything that makes my work easier instead of making it harder. imo the problem is not in c++, it is possible to write safe by default c++98. the bigger problems are that people don't know what is safe and what is not, and ub can go through unnoticed. i think interoperability with c++ is the right direction overall, but i would prefer actually readable source code like in swift/go/python, instead of ascii art that i don't want to touch because it makes compiler sad.

[@taowang6007]

The Idea in Val/Hylo looks really great. However I highly doubt how practical it will be in real world usage. Let's wait and see...

[@vladimirkraus1438]

I like Val/Hylo but it has drawbacks. I doubt it will seamlessly interop with C++ and it represents a paradigm shift. Programmers will need to unlearn the way they think when copying values by default in C++ because Val is the complete opposite of handling values...

[@maervo4179]

Just not a Language calling a List Object "Slice". They already did it in golang and i don't have an Idea why the fuck they use this term. Why not create a List, Set and so on? Java still has the best standard lib for Containers in 2024, this is sad 😂

[@hiongun]

pathetic. just let c++ go. you don't need 'seamless' access to c++. some partial, limited access to existing c++ code base would be sufficient. just move forward.

[@devon9374]

How Sway? How??

[@aasquared8191]

"just" let c++ go this is Google we're talking about, not your toy side project. they need c++.

[@_____case]

​​@@devon9374 This dude definitely doesn't have the answers. Any C++ codebase with layers of APIs on top of APIs face this common problem: How do they evolve away from C++? Seamless, bi-directional interop is the only way that they can replace pieces of the lower levels and the upper levels independently over time. "Partial, limited access to the existing C++ codebase" would only allow us to rewrite the codebase from the top down. Maybe that's good enough for some codebases, but others would get better results from a solution like Carbon.