Hacker News new | ask | show | jobs
by jupp0r 2674 days ago
One of the major hurdles in rewriting parts of C++ projects in Rust is that the interop surface between both languages is C. The necessary interface layer has created more bugs and work than the conversion saved. I'd really like to see more high-level interoperability between the two languages in the future, although C++ is a pretty fast-moving target at this point, with all the changes in C++20.
4 comments

Honestly, I wish a few different major languages would get together and start developing system ABIs that move beyond C as the interchange language.
But what would you put in such an ABI beyond what's in the C ABI? Beyond basic data types, struct defintions, and function definitions, languages begin to wildly diverge almost immediately.
Multiple return values. Ownership annotations. SIMD type support. String charset information.

More challenging would be to include stuff like allocation management (how to free a pointer when it's done), GC integration, function boxing, iterator/generator support. Vtables and cross-language inheritance is interesting but difficult.

One point of clarity: this would be an FFI ABI, not necessarily expecting that most datatypes would be laid out according to the ABI.

> Vtables and cross-language inheritance is interesting but difficult.

Windows' COM "solved" that problem. For example see C++/WinRT[0] for a modern C++ interface to COM. Or the C# .NET equivalents.

[0] https://github.com/Microsoft/cppwinrt

> The necessary interface layer has created more bugs and work than the conversion saved.

Is this from a project you did? This is weakness, for sure, but I'd be interested in hearing more about why it failed for you! We have some people working on this.

This was my experience when I was at Mozilla converting a part of Firefox to Rust. It also feels like a lot of Rust's safety guarantees go out the window when you are using the C FFI to talk between C++ and Rust. I'm not sure how bad it actually is in practice (vs just writing the whole thing in C++).
That's a proportional problem at least right? As months pass the more of your libraries converted to Rust the lesser the problem.

The potential party spoiler being third party code that's not practical to replace. In some cases even decades won't change it's nature, as a few examples have shown.

At some mid point you would have maximum C glue code in place, and then things get better after that.