Why, specifically, is Carbon better than C++?

[mbhvl]

First impressions are that Carbon is as verbose as C++; is not significantly more expressive; has modern memory management; but is otherwise a switch-in replacement for C++.
My biggest criticism of C++ and also C# is that "there is just so much of it". In precise terms, re-architecting an OOD project is just so enormously painful; and implementing any kind of domain often results in proliferating interfaces and inheritance everywhere. Writing the code can be a pleasure; but re-designing a project is just so much hard work.
For a new language to usurp C++, I would expect some game-changing killer features, substantially reduced verbosity and an easier experience when re-architecting.
If Carbon offers these I'd love to learn more. It's also fighting against the growing vogue for functional languages, which offer both power and economy of style.
What are the specific benefits of Carbon over C++?
Is the C-family not already crowded?
What am I missing?

[jonmeow]

If C++ works great for you, use it! We recognize that the Carbon Language won't be useful for everyone.

The intended benefits of Carbon Language are noted at the top of https://github.com/carbon-language/carbon-lang/blob/trunk/README.md:

---

Fast and works with C++

• Performance matching C++ using LLVM, with low-level access to bits and
  addresses
• Interoperate with your existing C++ code, from inheritance to templates
• Fast and scalable builds that work with your existing C++ build systems

Modern and evolving

• Solid language foundations that are easy to learn, especially if you have
  used C++
• Easy, tool-based upgrades between Carbon versions
• Safer fundamentals, and an incremental path towards a memory-safe subset

Welcoming open-source community

• Clear goals and priorities with robust governance
• Community that works to be welcoming, inclusive, and friendly
• Batteries-included approach: compiler, libraries, docs, tools, package
  manager, and more

---

To your comments, I will highlight that a key goal of Carbon is automated migration from C++ -- i.e., not re-architecting.

Of course, proof is in the implementation! Carbon Language is still experimental and definitely not ready for use yet. We went public early so that others could contribute to the design, and it sounds like you're more thinking about why you'd use this today -- it may not be in a state that's interesting to you, and that's fine! Hopefully there's something more for you after we've had some more years to work on implementation.

[L4stR1t3s]

I came here with the same question as OP and the answer isn't really satisfactory.

Fast and works with C++

C++ is fast and works with C++. What is the added value of using Carbon instead?

Solid language foundations that are easy to learn, especially if you have
used C++

Easy-to-learn if you already use C++? You can just keep using C++ then. What is the added value of using Carbon instead?
Easy-to-learn if you don't know C++ than learning C++? The heavy interoperability with C++ practically means you'll have to learn C++ as well. How many times do you have to go look at third party code to figure out how something works? Or step through it to debug something? So now you have to learn Carbon and C++, instead of just C++.

Easy, tool-based upgrades between Carbon versions

It makes using Carbon easier, but if I don't use Carbon I don't have issues upgrading Carbon. Sure C++ isn't great in this regard, but you're not fixing that problem, that problem still remains due to the heavy interopability with C++.

Safer fundamentals, and an incremental path towards a memory-safe subset

The heavy interoperability with C++ means you still have these issues. Just the Carbon code doesn't have these issues. Taking into account the fact that a whole new set of potential issues will result from using Carbon and C++ together, I think I'd rather deal with the original C++ issues.

Clear goals and priorities with robust governance
Community that works to be welcoming, inclusive, and friendly

Great things, but how a project is run isn't really a reason for the project to exist in the first place.

Batteries-included approach: compiler, libraries, docs, tools, package manager, and more

Ah, finally, some real issues with C++ IMO. But Carbon doesn't actually fix these issues for C++. Due to the heavy interoperability with C++, we still have to deal with the issues C++ has in these regards though.

I'm sorry but I still don't see the added value Carbon has to offer...

[xianjinfu]

The heavy interoperability with C++ means you still have these issues. Just the Carbon code doesn't have these issues. Taking into account the fact that a whole new set of potential issues will result from using Carbon and C++ together, I think I'd rather deal with the original C++ issues.

C++ is not memory-safe in general. In my opinion, interoperability mainly targets reusing the old systems. One can not get mem-safety using Rust if he use unsafe. If you choose unsafe, it's unsafe.

[OlaFosheimGrostad]

C++ is heavily based on duck-typing-abstractions with no protocols. If Carbon plays their cards right, formalize protocols and introduce a high level IR (which clang does not have) then they will have some high level optimization opportunities that would make it more interesting than C++, but it is too early to tell.

Right now there are more question marks than exclamation points, but that could change. What I feel lacking right now is:

• A conceptualization of a satisfactory error handling mechanism that makes sense for RAII (Go, Rust and Swift are primitive).
• Hints of what one can expect in terms of compiler support for memory management optimizations.