The Rust Foundation Wants to Improve Rust and C++ Interoperability (rust-lang.org) 6
The goal? "Make C++ and Rust interoperability easily accessible and approachable to the widest possible audience." And the Rust Foundation's "Interop Initiative" is specifically focused on the goal of interoperability "within the same executable," through either inline embedding that allows "integrated compilation", or foreign function interfaces.
To that end, a statement addressing "the challenges and opportunities in C++ and Rust interoperability" was announced this week by the Rust Foundation. Pointing out that the "Interop Initiative" was launched in February 2024 with a $1M contribution from Google, it now "proposes a collaborative, problem-space approach engaging key stakeholders from both language communities.
"Rather than prescribing specific solutions, this problem statement serves as a foundation for community input and participation in shaping both the strategic direction and tactical implementation of improved C++/Rust interoperability."
Their official problem statement outlines three "key strategic approaches."
- Improve existing tools and address tactical issues to reduce interoperability friction and risk in the short term.
- Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.
- Engage with the C++ community and committee to improve the quality of interoperation for both languages to help realize the mutual goals of safety and performance.
And it argues that interoperability "is essential to pursuing safety and performance which is maintainable and scalable." A significant amount of development has gone into libraries to facilitate interoperability with both C and C++, but from the language and compiler level, the situation remains largely unchanged from the early days of Rust. As the desire to integrate Rust into more C++ codebases increases, the value of making C++/Rust interoperability safer, easier, and more efficient is rapidly increasing. While each language takes a different overall approach, both view safety as an essential concern in modern systems. Both Rust and C++ have language- and standard-library-level facilities to improve safety in seemingly compatible ways, but significant benefits are lost when transiting the foreign function interfaces (FFI) boundary using the C ABI...
The consequence of this increased cost to interoperate means both C++ and Rust codebases are less able to access valuable code that already exists in the other language, and the ability to transition system components from one language to another is reduced outside of existing C-like interface boundaries. Ultimately, this reduction in freedom leads to worse outcomes for all users since technologists are less free to choose the most effective solutions.
To that end, a statement addressing "the challenges and opportunities in C++ and Rust interoperability" was announced this week by the Rust Foundation. Pointing out that the "Interop Initiative" was launched in February 2024 with a $1M contribution from Google, it now "proposes a collaborative, problem-space approach engaging key stakeholders from both language communities.
"Rather than prescribing specific solutions, this problem statement serves as a foundation for community input and participation in shaping both the strategic direction and tactical implementation of improved C++/Rust interoperability."
Their official problem statement outlines three "key strategic approaches."
- Improve existing tools and address tactical issues to reduce interoperability friction and risk in the short term.
- Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.
- Engage with the C++ community and committee to improve the quality of interoperation for both languages to help realize the mutual goals of safety and performance.
And it argues that interoperability "is essential to pursuing safety and performance which is maintainable and scalable." A significant amount of development has gone into libraries to facilitate interoperability with both C and C++, but from the language and compiler level, the situation remains largely unchanged from the early days of Rust. As the desire to integrate Rust into more C++ codebases increases, the value of making C++/Rust interoperability safer, easier, and more efficient is rapidly increasing. While each language takes a different overall approach, both view safety as an essential concern in modern systems. Both Rust and C++ have language- and standard-library-level facilities to improve safety in seemingly compatible ways, but significant benefits are lost when transiting the foreign function interfaces (FFI) boundary using the C ABI...
The consequence of this increased cost to interoperate means both C++ and Rust codebases are less able to access valuable code that already exists in the other language, and the ability to transition system components from one language to another is reduced outside of existing C-like interface boundaries. Ultimately, this reduction in freedom leads to worse outcomes for all users since technologists are less free to choose the most effective solutions.
The Mozilla foundation could learn something them (Score:3)
C++ interop is hard (Score:4, Interesting)
Will be interesting to see what form this interoperability takes. C++ is a notoriously difficult language to interoperate with from other languages because of the many impedance mismatches between it and other languages. For example C++'s object model includes multiple inheritance which is actually widely used. Or C++ template classes. And until recently ABI compatibility across compilers and compiler versions was not consistent. This includes name mangling as well as the vtable structure.
Many current languages that interoperate with C++ rely on wrappers written in C++ that export extern C objects.
I suppose another difficulty would be that any C++ code a Rust program interacts with is unsafe and does not support any of the Rust safety semantics like borrow checking. But that problem exists with any C library you interact with also, so it's a problem Rust programmers are no doubt already used to dealing with.
Meanwhile Rust-inspired safety principles and constructs are being added to C++ right now in the form of Circle C++ and an enhanced libstdc++, and in the near future in the C++ standard. The future for C++ is quite bright and will allow more cost-effective ways of retrofitting safety onto existing C++ code.
Re: (Score:2)
For ABI interfacing , the C ABI is pretty much the de-facto one on *nix (apart from MacOS) so all they need is a working C interface and they're sorted. Any kind of C++ interface would probably only be a partial solution as higher level constructs from one language (eg non mangled class, method, variable names) will mean nothing to another language. It has to be strictly system loader stuff.