And memory layout through repr(align). I also disagree that rust should slow down. There are a number of critical features that need to land for the language should “stabilize” (it is stable).
I agree a few more things need to get in. But AFAICT the abi is not stable and you may need to recompile all dependencies when updating the compiler.
I would like it to be "feature complete" without having regular churn like C++. Or the recent battle with Python that was a sort of last straw for Guido. C is almost completely stagnant and that's a good thing. Posix as well. If you want to be a long term systems language it seems stability is a critical feature and Rust needs to get that in the next few years. IMHO or course.
There is a trade-off between "provide types a stable layout" (required for a stable ABI) and "optimize my program as much as possible" (e.g. change type-layout using profile-guided optimization to put hot fields inside the same cacheline).
In Rust, if you want to give a type a stable ABI, you just need to stamp `#[repr(C)]` on it. Otherwise, you get optimizations by default.
The amount of types and functions in a code-base is usually much larger than its surface API, and this decision balances optimizing properly, while still providing a stable API.
C++ didn’t have a pragmatically stable ABI until like a year ago on MSVC. You had to jump through hoops with extern C APIs or COM and the like. The same is true in Rust, and even in C++ with different tool chains on windows.
The only language with a stable ABI is C (and that is more accidental than explicit). It’s too hard a guarantee to provide with little ROI when you have a workaround, and it chains your implementation to ABI details.
Just as an example, rustc is very clever about struct layout and liberally pads fields to get superior alignment. This may change in the future depending on architectures and paradigms. You don’t want your ABI to define a padding scheme for your targets today, you want future compilers to be smarter.
If you want to guarantee stability you need to align the memory manually on the structs that cross ABI boundaries like shared libraries, and any kind of language construct that lets you do future tricks with ABI within a binary but provides escape hatches for things along the boundary would look identical to how you do things today via attributes.
TL;DR ABI stability in the compiler is simply not desirable. You can already do it manually and you should do it manually. It’s fairly ergonomic as well.
Furthermore, GCC/libstdc++ have maintained ABI compatibility for at least 15 years now, even across an incompatible change of std::string and std::list required for C++11 conformance, so in practice the situation with C++ looks better than with Rust.
