Hacker News Reader

Comment by est31 | Hacker News Reader

A big thing missed here is compatibility. The systems programming market is huge but most of it is covered by C/C++ programs, many of which being giant codebases with millions of engineer hours inside them. You can't just rewrite them in Rust. And Rust will always be second in place when it comes to interacting with C/C++ codebases, C++ will always be better at it, and if it's only the explicit safety barrier.

So languages like Rust are relegated to picking up the new greenfield codebases and some few codebases where engineers felt courageous enough to introduce it.

Overall, the signs are good though. I think it's much easier to onboard new engineers to Rust rather than to the company specific dialect of C++.

View on HN

I'm hoping that with the advent of projects like autocxx [1], the C++ compatibility story will rapidly change. Templates and some of C++'s more exotic features will always be an interop issue but Rust's ergonomics and type system are addicting.

I've been experimenting with "bidirectional" (for lack of a better word) refactoring in autocxx where the bulk of the C++ implementation stays the same but wrapped in a safe Rust interface (using autocxx to generate the underlying interop) that is then reexposed by another run of autocxx to the rest of the C++ code. New Rust code can use the safe interface while old code is refactored to use the now (slightly) safer wrapper over the Rust interface. This allows for very intentional, piecemeal refactoring across the code base.

Rust's compatibility with other languages like Python and Javascript is already, imo, second to none thanks to a few well designed libraries and the macro system. The only language that comes close is C# with its IronPython integration, except with Rust it's a lot easier for library authors to integrate runtimes. It took me less than a day to construct a JS/Python monstrosity with an absurd call stack (Node => Rust => Python => Rust => Node => Rust => Python) when I needed to wrangle together a bunch of legacy proprietary libraries in webapp form.

Like you said, the signs are good for Rust's interop story in general.

[1] https://github.com/google/autocxx

You're right about the massive amounts of C/C++ code out there. I'd disagree that the integration is harder than with C++, though.

Calling Rust from C and vice versa is fairly straightforward and there are automatic code generators for doing so. Things just get wrapped into an `unsafe` block and that gives you the same guarantees you'd have with C++ (none, basically). From there you can start to gradually rewrite critical parts in safe Rust and profit from the cargo ecosystem along the way. In that sense there's even an advantage for Rust over C++ in my book.

Integrating with C is easier than with C++ but it still needs those safe wrappers. With C++ you can use stuff directly, and maybe sometimes have to convert between say C and C++ strings. Integrating with C++ is much harder, especially if some C++ features are used. What if you have to inherit a class to do something? What if there is a generic function that you need to invoke? Even tasks as simple as catching exceptions are difficult. Things have improved with dtolnay's cxx thankfully.

Calling C++ libraries from Rust is in general impossible. The more useful the library is, the less likely it is that Rust can call it. As the languages evolve, that will sharpen.

There is no "C/C++" code. Using the expression mainly generates confusion, most usually in the person saying it.

Reply on news.ycombinator.com