There's also degrees of interop - there's "rust can call a c++ dylib directly" but there's also "rust and c++ can be co-compiled". The latter is the critical path for migrating large projects from C++ to safer languages, because what you really want is to be able to replace your implementation class-by-class or file-by-file. Without a good interop story you have to essentially replace huge amounts of code in a single shot, and as the minimum subset increases in size the plausibility of successfully completing such rewriting gets lower and lower. It's a large part of why despite originating rust, mozilla has been unable to rewrite gecko in rust.
Creating a C wrapper is not a solution for the problem of migration.
3 comments
[ 1.9 ms ] story [ 17.9 ms ] threadC++ is hardly interoperable with itself. Keeping abi stability is a nightmare.
I usually expose an C api from the C++ lib, and wrap the C api in C++.
The article does not give any technical details but some vague AI stuff and improve tools etc.
Possibly it will be about polishing/automating this kind of flow.
There's also degrees of interop - there's "rust can call a c++ dylib directly" but there's also "rust and c++ can be co-compiled". The latter is the critical path for migrating large projects from C++ to safer languages, because what you really want is to be able to replace your implementation class-by-class or file-by-file. Without a good interop story you have to essentially replace huge amounts of code in a single shot, and as the minimum subset increases in size the plausibility of successfully completing such rewriting gets lower and lower. It's a large part of why despite originating rust, mozilla has been unable to rewrite gecko in rust.
Creating a C wrapper is not a solution for the problem of migration.