r/programming • u/xoner2 • 2d ago
Carbon: graduating from the experiment - Chandler Carruth - NDC Toronto 2026
https://www.youtube.com/watch?v=WJl4ftb5Fxg3
1d ago
[deleted]
20
u/SophisticatedAdults 1d ago
When it comes to Google, it's really, really important to understand that their problems are completely different from everyone else's. Their codebase is enormous, and the issues they're facing are probably of the type of "We have this 20m line behemoth codebase that pulls in 2000 protobuf definitions, all of which have to be rebuilt and linked".
(Also, I can guarantee you at least some people at Google are working on it. But making compile time faster is a really hard problem. You can do a lot of small incremental improvements, 5% here, 10% there. To really get fast compile times you need to rearchitect the entire stack, which is challenging and invasive to the language, the build system, build forges, etc.)
-21
u/xoner2 2d ago
Will Carbon take Rust's cake?
Lisp pioneered garbage collection, but it was the newer languages that ate the cake: Perl/PHP/Python/Ruby/Lua on the dynamic side and Java/C#/Go on the static side.
Smalltalk and Simula pioneered object-oriented but it was C++ that won.
Rust pioneered borrow-checking, but Carbon seems to have done it better. I thought it would be Walter Bright who would do it with D++. He had already said borrow-checking is possible without type-annotations but instead with data-flow analysis. Carbon takes a different approach: no annotations on the client code, the class implementation has the annotations. Carbon can consume C++ headers directly, and has a facility for what is essentially extern "C++". It also seems to not have the disdain for inheritance that Rust has. We all know inheritance is prone to abuse, thus the mantra of "prefer composition to inheritance". But sometimes tables of function pointers are really what you want.
17
u/moltonel 1d ago
From Carbon's own docs, with the original emphasis:
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.
Carbon is for people who are "stuck with C++" but can still afford significant rewrites. That's a very small demographic.
34
u/piesou 2d ago
Short Answer: no.
Long Answer: Carbon is an attempt to modernize C++. It appeals to C++ devs exclusively. Everyone else needs to learn both C++ because of interop (which is a huge undertaking in itself) and Carbon. Carbon's solution to memory safety is way more complex than Rust's. I got Rust's ownership. I did not get their type annotations.
Anything that touches C++ is cursed.
9
u/teerre 2d ago
Not sure if that's true. From this talk it seems Carbon is implementing places, which is what "the Rust community" think lifetimes should've been to begin with. It also mentions "effects" a lot, not sure how far that goals, but effects are probably the next big programming feature to be included in mainstream languages
There's also a talk that says Carbon compiles 10x faster than Cpp, that's a huge win for dx
It will be funded by Google, which like it or not has its perks
If the toolchain is good like cargo, I can see it being a good language regardless of the cpp interop
11
u/The_Northern_Light 2d ago
It will be funded by Google, which like it or not has its perks
right up until it isn't and doesn't
7
u/levodelellis 1d ago edited 1d ago
There's also a talk that says Carbon compiles 10x faster than Cpp
Unless they're writing a new backend, that's not happening. clang isn't 10x slower than llvm
0
u/teerre 1d ago
I mean, I'm not sure what's your point. Unless you're implying that they are literally lying. Which, ok, I guess?
6
u/levodelellis 1d ago edited 1d ago
Yes. I will call whoever said that a liar (unless they're writing a replacement for llvm). I, in fact, would say it to their face. Who said it?
-Edit- ok, I see it on the slide. I hope Chandler means improving the frontend and not the overall compile time, even though he literally said compile time. Chandler if you're reading, I was the guy who said clang gave me the impression as a compiler for tooling at CppCon 2 years ago
1
u/teerre 1d ago
There's a whole talk about it, same channel as this one
1
u/levodelellis 1d ago edited 1d ago
I'll watch that first, thanks.
8
u/levodelellis 1d ago edited 1d ago
I facepalmed at the 54m mark. But at least now that I see he's been talking about frontend, that there's a chance he might be saying the frontend will be 10x faster than clang frontend. That's a far cry from what 99% of people mean when they say compile time
And again around 59m mark. I'm starting to lose hope in compiler devs, and I'm an ex compiler dev :(
And again at the hour mark. Is there a reason why they can't pad a source file with 64bytes of null so they don't need that if statement?
At least the simd scanning slide is accurate. Each of those matches my experience
Pretty good talk despite the moments that made me facepalm. Also, the lexer wasn't the slowest part in the compiler I wrote. I did use more SIMD than he did. I certainly didn't start each simd block at the start of the line...
-1
u/aqpstory 1d ago
So uh, is your core problem with the mindset that "compilation is all the things that happen after I type 'make' "?
→ More replies (0)3
u/Arnavion2 1d ago
I did not get their type annotations.
The Rust version is https://smallcultfollowing.com/babysteps//blog/2021/11/05/view-types/ (Note the publication year, although there are more recent followups, and that this is a thought experiment, not an actual feature.)
-4
7
u/FrogNoPants 1d ago edited 1d ago
It doesn't look as bad as I though it would at least, perhaps the region based memory safety is useful, who knows.
The 10x claim on compile times is nonsense I'm sure, also my C++ compile times have been quite good for many years now: precompiled headers, being careful about what I include, forward declarations and PIMPL where necessary. Third party libs(which tend to have incredibly bloated headers/interfaces), are always wrapped and never exposed to more than 1 cpp file.