carbon-lang

Carbon's "Interoperability philosophy and goals" page (my emphasis): > The C++ interoperability layer of Carbon allows a subset of C++ APIs to be accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed from C++ code. > The result is that it will often be reasonable to directly expose a C++ data structure to Carbon without converting it to a "native" or "idiomatic" Carbon data structure. Although interfaces may differ, a trivial adapter wrapper should be sufficient. > There should be support for most idiomatic usage of advanced C++ features. A few examples are templates, overload sets, attributes and ADL. > Non-goals > Never require bridge code > Support for C++ exceptions without bridge code https://github.com/carbon-language/carbon-lang/blob/trunk/do...

luck getting the C++ Standards Committee to agree on what to remove. >> a clean reboot can converge on a "better" solution Yes, but would it be backward compatible with existing C++ codebases? If the "clean reboot" is too different or not backward compatible enough would it be adopted by existing C++ users / the community? If it required significant effort to port old C++ code to the rebooted version, why would the rebooted version be chosen over another language?(for example: Rust, Go, Ada, Zig, etc.) Perl tried an ambitious rewrite from Perl 5 to Perl 6 and it did not work very well: it took too long, did not see wide adoption, and ultimately Perl 6 was renamed Raku. Perl did not have to push Perl 6 changes through a standards committee or try to get a dozen or more compiler implementors to agree. (https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil...) While it is possible that C++ could evolve into a smaller, cleaner version of itself, I do not think it is likely given all of the forces involved.