Comment by burakemir

Congrats to the folks involved!

Having previously led Rust at Google, I remember several great cross-company discussions with Microsoft engineers on interop.

Companies with massive C++ codebases use Rust as a pragmatic hedge. C++ as we know it is unlikely to ever become fully memory safe, and unlike C++ standard committee voices who dispute the urgency, major industry players need actionable solutions today.

Because these existing codebases are so vast, Rust must have a viable C++ interop story. However, defining what "good interop" means remains tricky. C++ routinely tolerates aliasing and relies on patterns that violate Rust's aliasing rules. Shared backend infrastructure (like connecting rustc directly to MSVC backends) helps with ABI layout, cross-language inlining, and toolchain parity, but it doesn't solve the core type system divergence.

The fundamental obstacle is type systems:

* Boundaries remain unsafe: Compilers cannot statically verify C++ safety invariants. Crossing the boundary stays in unsafe territory.

* Idiomatic C++ structures often cannot map cleanly into Rust idioms. This forces developers into onerous safety comments or heavy wrapper layers. At some point, application writers will consider serialization / in-process RPC or a full rewrite as a cheaper or cleaner option of getting interop.

Bridging this gap on the ABI level is pragmatic, but pushing Rust's semantics to accommodate C++ edge cases risks compromising "pure Rust" goals. I doubt the broader Rust community will favor complicating Rust's safety model just to smooth over legacy C++ patterns.

To be clear: practical interop is a worthwhile investment, but "seamless interop" needs serious qualification. It will always have hard limits. There will always be friction at the boundary and it will always be a tough sell.