> In particular, C++ is fundamentally hostile to cross-language interopt
C++ adheres to Itanium C++ ABI [1] which in turn adheres to SystemV ABI [2].
> to the degree that even C++ compilers struggle to maintain compatibility between themselves.
"Struggle" is to follow the Itanium C++ ABI spec.
> For a language to work with C++, its compiler basically needs to contain a C++ compiler as well (as Carbon does). Moreover, simply being "compatible with C++17" is only the very first step to practical usage, e.g. consider how much work the Clang developers put into reverse engineering GCCisms.
I think you're conflating different terms. Carbon and other similar C++-like frontends are essentially transpilers from C++-like grammar to C++.
Being "compatible" requires no reverse engineering but as I said above it's just a matter of following the C++ ABI spec (for interop between C++ compilers) and following the SystemV ABI spec (for interop between fundamentally different languages).
* C++ adheres to Itanium C++ ABI [1] which in turn adheres to SystemV ABI [2].*
Uh.. MSVC does not adhere to the Itanium C++ ABI. ISO C++ does not specify any name mangling scheme, in fact I doubt the standard even mentions name mangling.
I think you're conflating different terms. Carbon and other similar C++-like frontends are essentially transpilers from C++-like grammar to C++.
Carbon resembles Rust far more than C++, to say the least. In my experience C++ developers criticize its difference in syntax more than anything else.
Anyway, setting aside the differences in syntax, the point I was trying to convey is that C++ is especially difficult to call from other languages, largely due to templates and/or sheer complexity. For a language to take a C++ header and be able to understand something as basic as std::vector, it needs to have quite a sophisticated understanding of C++ and its implementation. By comparison, Java is readily available in other JVM languages like Kotlin and Clojure, albeit those are managed languages.
Being "compatible" requires no reverse engineering but as I said above it's just a matter of following the C++ ABI spec
Not at all. A C++ ABI does not make it possible to magically understand C++ code. If you disagree, then please explain how a platform’s C++ ABI is sufficient to understand a type like std::string from another language. In particular even a vocabulary type like std::string is not compatible between libc++ and libstdc++, i.e. the two most binary compatible C++ standard library implementations available today.
C++ adheres to Itanium C++ ABI [1] which in turn adheres to SystemV ABI [2].
> to the degree that even C++ compilers struggle to maintain compatibility between themselves.
"Struggle" is to follow the Itanium C++ ABI spec.
> For a language to work with C++, its compiler basically needs to contain a C++ compiler as well (as Carbon does). Moreover, simply being "compatible with C++17" is only the very first step to practical usage, e.g. consider how much work the Clang developers put into reverse engineering GCCisms.
I think you're conflating different terms. Carbon and other similar C++-like frontends are essentially transpilers from C++-like grammar to C++.
Being "compatible" requires no reverse engineering but as I said above it's just a matter of following the C++ ABI spec (for interop between C++ compilers) and following the SystemV ABI spec (for interop between fundamentally different languages).
[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html
[2] https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x...