Why you should, actually, rewrite some of it in Rust

Re:Why you should, actually, rewrite some of it in Rust by Animats on Wednesday July 12, 2017 @02:49PM (#14755361)

The trouble with mixing Rust and C/C++ is that you tend to get Rust with C/C++ unsafe pointers. Most of the examples of this pass C raw pointers into rust, Rather than passing a Rust Vec into C. Or even passing STL strings and vectors into Rust. So, instead of passing Rust's array size information into C, they propagate C's lack of size information into Rust. Typical example: [1]

    pub extern "C" fn count_substrings(value: *const c_char, substr: *const c_char) -> i32

If you incrementally convert from C/C++ to Rust, you end up with those constructs in the final Rust program. Not good.

[1] http://siciarz.net/24-days-of-rust-calling-rust-from-other-l...

[ Parent | on HN ]

Re:Why you should, actually, rewrite some of it in Rust by dbaupp on Wednesday July 12, 2017 @03:44PM (#14755927)

You only end up with them in the final program with a naive translation that makes life hard for yourself. Using the native types is much nicer (even ignoring any safety benefits), and so people are naturally encouraged to do so. For instance,

- the C interface can easily be thin wrappers around pure "nice" Rust functions, that just do the necessary unsafe conversions

- and, whether or not that is used, when a function is no longer being called from C (that is, everything that calls it has been converted to Rust) the arguments can be switched to something more natural and strong static typing will point out all the places that need to be updated.

I cannot believe that a pure Rust codebase would want to be passing raw pointers around. And the alternatives don't seem at all better: only ground-up complete-rewrite migrations (hard to justify so often won't even start) or not migrating at all (meaning one has a C codebase that is still full of unsafe pointers).

[ Parent | on HN ]