The Rust Foundation has just released a statement on Rust and C++ interoperability and Google is ponying up $1000,000 to see that it gets done.

There is a Rodgers and Hammerstein show song called The Farmer And The Cowman with the first lines:

The farmer and the cowman should be friends,
Oh, the farmer and the cowman should be friends.
One man likes to push a plough, the other likes to chase a
cow,
But that's no reason why they cain't be friends.

and it goes on to explain the differences between the two to the extent that in the end you just have to conclude that they should be mortal enemies.

So it is with Rust and C++ programmers. The Rust programmers like to push the boundaries of the borrow checker and the C++ programmers like to chase bugs. The main point is that there really is a lot of animosity in the two camps for the other. Let's face it, the C++ guys have a lot to lose and a lot of work to put in to join the Rust guys.

So why not work together and keep the identities separate?

This is, sort of, what the announcement is trying to convince us:

The initiative recognizes that both C++ and Rust have essential roles in the future of systems programming. While both languages excel in similar domains, using them together effectively is crucial for organizations seeking to balance safety and performance with maintainability. The core challenge lies in developing a mature, standardized approach to C++ and Rust interoperability, despite Rust's historical focus on C compatibility.

The plan of action seems to be:

• Improve existing tools and address tactical issues within the Rust Project 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.

"Engage with the C++ community and committee", well good luck with that!

At a more fundamental level,  what is being proposed here is  defining a Foreign Function Interface (FFI) and some tools that can be used to build mixed language projects. There are some existing crates that let Rust call C and C call Rust, but these have their own problems.

The proposal is to use the C ABI (Application Binary Interface) to define the transfer of data between the two languages. This makes good sense, but means that both of the languages have to negotiate their way through the constriction of the C ABI. Then there is the problem that a connection between the two languages could well introduce unsafe code on both sides of the connection.

The problem of interoperability between any two languages generally comes down to mapping the data types between the two, often referred to as marshalling. The marshalling itself isn't difficult and there are plenty of examples of it in action - Python to C, C# to C and so on - but in this case we are looking for something easy to use and safe. I'd like to see how aliasing in C is going to be dealt with, not to mention pointers in general!

One thing is obvious. If this is to be achieved it is going to need programmers who are fluent in both languages at an exceptional level.

•  Mike James is Chief Editor of I Programmer and the author of several programming books in the I Programmer Library. Safe and unsafe behavior is one of the topics in his recent book "Deep C Dives". 

More Information

Rust Foundation Releases Problem Statement on C++/Rust Interoperability
C++/Rust Interoperability Problem Statement

Related Articles

The Feds Want Us To Move On From C/C++

DARPA Wants All C Converted To Rust

Is Rust Safe?

Rust Twice As Productive As C++

C23 - What We Have To Suffer

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

<ASIN:B0D6LZZQ8R>