> But this guarantee applied to C++ It actually doesn't. There's nothing in the standard about it; it's up to compilers. See https://stackoverflow.com/question

> But this guarantee applied to C++ It actually doesn't. There's nothing in the standard about it; it's up to compilers. See https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects https://stackoverflow.com/questions/46746878/is-it-safe-to-l... > but mostly forces Rust crates to be open-source. In practice how many closed source C++ libraries are there? I can't recall using a single one despite working on many closed source C++ applications. I'm sure they exist but a closed source Rust crate could just do what many C++ libraries do anyway - wrap a C ABI with a thin open source Rust shim. > which is the reason it's used today. Obviously it helped that C++ was backwards compatible with C, but all of those languages you mentioned use garbage collection and need some kind of runtime so they were never in the running for a systems programming language like C++. (I know "systems programming" is ambiguous but you know what I mean...) I totally agree that the requirement of backwards compatibility with C made C++ a lot shitter. The most obvious examples are the automatic type coersion and the insane type syntax.