A.
Because C++ is too complex? And its standard library speed not as fast as it could be, because of its stable ABI: Reddit - Dive into anything
There is no question that libstdc++'s implementation of <regex> is not well optimized. But there is more to it than that. It’s not that the standard requirements inhibit optimizations so much as the standard requirements inhibit changes.
[…]
The minute libstdc++ (and other standard library implementations) started shipping an implementation of C++ regular expressions, they bound themselves to a specific implementation that could not be changed in a way that impacted the ABI of the library. And while they could cause another ABI break to fix it, standard library implementers don’t like breaking ABI because people don’t upgrade to standard libraries that break their code.
When C++11 forbade basic_string copy-on-write implementations, libstdc++ had an ABI problem.
https://lemire.me/blog/2022/08/09/hello-world-is-slower-in-c-than-in-c-linux/
It’s intriguing to contrast Carbon with (C++), Julia, Rust, Zig, how it’s template/generics system diverges from C++ and Julia, also its error model. I can’t see that Cabon has multiple dispatch (or multimethods), even though Strostrup proposed for C++, or are “mixins” the same, or similar enough:
For example, mixins for implementation reuse and generics for separating interface from implementation. This allows Carbon to move away from multiple inheritance, which doesn’t have as efficient of an implementation strategy.
Classes by default are final
It’s intriguing to look at the goals; and non-goals, e.g. “Stable language and library ABI”, because C++ has a stable ABI, and it’s holding C++ back, meaning its standard library can’t be fastest.
See FAQ: carbon-lang/docs/project/faq.md at trunk · carbon-language/carbon-lang · GitHub
Why not improve C++?
A lot of effort has been invested into improving C++, but C++ is difficult to improve.
For example, although P2137 was not accepted, it formed the basis for Carbon’s goals.
Why not fork C++?
[…]
Why not Rust?
If you can use Rust, ignore Carbon
please see Carbon’s success criteria.
See: carbon-lang/docs/project/goals.md at trunk · carbon-language/carbon-lang · GitHub
Goals
[…]
Software and language evolution
[…]
Be mindful of legacy. Globally, there may be as many as 50 billion lines of C++ code. Any evolution of Carbon that fails to account for human investment/training and legacy code, representing significant capital, is doomed from the start. […]
Support software outside of the primary use cases well. There are surprisingly high costs for developers to switch languages. […]
All unsafe or risky operations and interfaces must support some dynamic checking.
[…]
Syntax should parse with bounded, small look-ahead. Syntax that requires unbounded look-ahead or fully general backtracking adds significant complexity to parsing and makes it harder to provide high quality error messages. The result is both slower iteration and more iterations, a multiplicative negative impact on productivity. Humans aren’t immune either; they can be confused by constructs that appear to mean one thing but actually mean another. Instead, we should design for syntax that is fast to parse, with easy and reliable error messages.[…]
Interoperability with and migration from existing C++ code
[…]
We must be able to move existing large C++ codebases – some with hundreds of millions of lines of code and tens of thousands of active developers – onto Carbon. […]
Automated source-to-source migration of large segments of large-scale idiomatic C++ code bases with high fidelity. […]
Support for bi-directional interoperability with existing C++ code. We need Carbon code to be able to call into C and C++ libraries with both reasonable API clarity and high performance. […]
Non-goals
There are common or expected goals of many programming languages that we explicitly call out as non-goals for Carbon. […]
Stable language and library ABI
We would prefer to provide better, dedicated mechanisms to decompose software subsystems in ways that scale over time rather than providing a stable ABI across the Carbon language and libraries. Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals. […]
Backwards or forwards compatibility
I can’t see that this language has multiple dispatch (or multimethods), even though Strostrup proposed for C++.
Error (not exception) handling: carbon-lang/docs/project/principles/error_handling.md at 075b3aba1bdbcb26488529fe35778981d219e5ca · carbon-language/carbon-lang · GitHub
Carbon errors, unlike exceptions in C++ and similar languages, will not be propagated implicitly. Instead, Carbon will very likely need to provide some explicit but syntactically lightweight means of propagating errors, such as Rust’s ? operator
B.
I believe the developers of the language are very well aware of C++20, and probably have it or C++23 in mind with “modern C++”; they at least mention C++20 is several places, in the docs, e.g.
Interoperability will target C++17. Any interoperability support for future versions of C++, including features such as C++20 modules, will be based on a cost-benefit analysis.
and: carbon-lang/proposals/p0142.md at 075b3aba1bdbcb26488529fe35778981d219e5ca · carbon-language/carbon-lang · GitHub
Characters in identifiers and whitespace
We will largely follow Unicode Annex 31 in our selection of identifier and whitespace characters. […]
For example, this list includes U+30EA (KATAKANA LETTER RI), but not U+2603 (SNOWMAN), both of which are permitted in identifiers in C++20. […]
we should use Annex 31 as a basis for our decisions, and should expect strong justification for deviations from it.
Note that this aligns with the current direction for C++, as described in WG21 paper P1949R6.
But you can choose to only use ASCII in your own code (just as Python, and I think still C++, forces you to use for identifiers), if I recall, no (exported) function of a package should be non-ASCII, according to some style-guide, so I think the issue is overblown. I like π and ℯ and e.g. ⊻ but nobody is forced to use, you always have ASCII equivalent; for all operators except that last one, then the ASCII-only in functional form.