The Rust Foundation Wants to Improve Rust and C++ Interoperability (rust-lang.org) 17
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)
Re: (Score:2)
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.
Re: (Score:2)
> And until recently ABI compatibility across compilers and compiler versions was not consistent.
No, no, it was consistent. As in: not working. But now there are two 800-pound gorillas: gcc and msvc. Compilers on Unix look and feel like, and interoperate, gcc. Compilers on Windows interoperate with msvc.
Re: (Score:2)
You forgot Clang + LLVM, arguably more important than MSVC considering it's used by orders of magnitude more devices and LLVM underpins Rust.
Re: (Score:2)
arguably more important than MSVC considering it's used by orders of magnitude more devices
Usable on, for sure. Used by? I don't know- that seems unlikely to me. Have anything to back it up?
gcc is still the default on every distribution I've ever used.
Re: C++ interop is hard (Score:2)
The future for C++ is quite bright and will allow more cost-effective ways of retrofitting safety onto existing C++ code.
I think the future of C++ looks a bit like this:
https://xkcd.com/927/ [xkcd.com]
Right now it's in the middle pane. The future is the one on the right.
Re: (Score:2)
The biggest problem are the platform ABIs that are not expressive enough for either rust or C++. That means both sides do tricks to smuggle extra information through the C-compatible platform ABIs -- or to pass constructs entirely around that ABI. E.g. name mangling is used to smuggle function overloading through the C ABI by encoding type information into the symbol name which is just a string.
Things going around the ABI is all the stuff that C++ requires to always be in a header file. Those headers get di
Historical Reference (Score:2)
COBOL had the COMPUTE statement for compatibility with the most popular language at the time: COMPUTE and write it like you would in FORTRAN. Can you still compile K&R C in C++? Ignoring a list of warnings longer than the source code, of course. So it's kind of logical for Rust to do something similar.
Re: Historical Reference (Score:1)
No Thanks (Score:2)
Re: (Score:3)
Templates and meta programming result in opaque code where the reader has to go unravel abstractions and produces borderline useless stack traces. It's the old "my code is self-documenting, but it's only self-documenting for me" which people who have never worked in a true technology company seem to think is "clever". In practice, it's almost never the right approach, the Google C++ style guide states it best:
"Code that uses templates in complicated ways is often unreadable, and is hard to debug or maintain