Why not RUST?
(I never use RUST but heard it has been touted as a better C++)
(I never use RUST but heard it has been touted as a better C++)
Rust seems utterly uninterested in supporting gradual migration of C++, which makes porting millions of LoC untenable.
Additionally rust has no interest in ABI stability, which is actually important (the rust ABI stability story is to my knowledge “expose a C FFI layer”)
There certainly are problems for which ABI stability might be important. It would probably be desirable to do better than "Expose a C FFI layer" and deliver such stability. It's not at all clear that you can actually do that today without a terrible cost.
In C++ the situation is that de facto lots of things are frozen in order to deliver ABI stability. Having no actual ABI layer to stabilize, in practice major C++ implementations just... froze everything that seemed like somebody might ever possibly expose it, and any time they weren't conservative enough they got shouted at by developers who had, inevitably, depended upon a stability nobody even realised could be cared about.
The cost of that freezing is that everything affected is worse than it should be, for everybody, not just those who needed all, or even some, of the ABI stability. Where Rust is entitled to re-arrange a data structure (A,B,C,D) as (D,A,C,B) because that's 5% faster and has 8 byte smaller aligned size, in C++ they daren't do any such thing, even if they never specified this structure because you can just expose it anyway and then rely upon that never changing thanks to ABI stability...
Maybe, Rust will adopt an actual ABI mechanism which lets you deliberately expose some non-C flavour data structures or functions in a stable way, thereby promising they will keep some particular shape forever. It's certainly possible for Rust to adopt such things without having the inadvertent problem C++ got because it has things in place which let it write that down cleanly which C++ didn't really do.
Rust's repr attribute controls how a type is represented in memory, so today you'd use the attribute [repr(C)] to indicate that you want the structure laid out the way C would for ABI compatibility reasons, but you could imagine a repr(Awesome) for some hypothetical Awesome agreed ABI with shinier features or a repr(Swift) or whatever.
Like when you're a library, as FoundationDB is.
C and C++ have a specific approach to ABI stability that induces a specific kind of misery (more generally the ABI is fragile), but Swift is ABI stable without that misery.
If the first thing you need to do to in order to be a library is lose all your language safety features by marshaling to and from C/C++ to create the actual API, even when both sides of the API are in the same language that's just a sad waste.