4 ms·

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code This is a false dic

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code This is a false dichotomy. Bugs are concentrated in new code, so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. Going backwards and rewriting low bug density code should not be a priority. Both of your alternatives only address existing code.

Slighted 4y ago
Which is why I wrote "Is it more efficient in the long run?" Ideally there would be an open probe into the project as a whole decide whether or not the switch is a good idea, and whether or not such a change should be accomplished with Rust.
- bluejekyll 4y ago
  This isn’t a simple thing to answer as it’s specific to any given project. If something is millions of lines of code, will anyone ever fund a full rewrite that could take years? In that case finding areas to plug-in Rust is probably the better strategy. See the Linux kernel and drivers being able to be in Rust. On the other hand, if something is only a few thousand lines of code, a rewrite wouldn’t take much time and might be worth it.
andsoitis 4y ago
> so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. How well does Rust inter operate with C or C++ code? When you interoperate, do the security issues persist or do they disappear automagically?
- Arnavion 4y ago
  There is unsafety at the FFI boundary. The C functions will deal with pointers, so the Rust side will have to use pointers too. The Rust side will normally thunk it into safe Rust (convert pointers to references by introducing lifetimes, wrapping in types with destructors, making sure to add or remove Send / Sync impls as necessary, etc) so that the rest of the Rust code that's not at the boundary can be safe. So if you have a Rust function that receives a pointer and a length representing the array, it will translate that into a Rust slice by trusting the pointer and length. Of course if the C caller gave a garbage pointer or a length that's bigger than the actual C array, then the "safe" Rust code that uses that slice will still be illegal. C++ interop has some additional complexity because of templates, methods, inheritance, etc, that's handled by the cxx Rust library. I don't know much about it.
- bluejekyll 4y ago
  Rust allows for zero overhead FFI between itself and C. For C++, there are some crates working to make that easier so that C++ objects can be shared, but generally, the C ABI is the common interop layer. As to the security issues persisting, yes, the C security issues will persist. But, what’s nice is that the Rust code is safe and you just need to attest to the compiler that the usage of those C APIs is safe. Essentially the Rust code is safe, but it’s still your responsibility to prove that the C code is safe.

Slighted 4y ago

Which is why I wrote "Is it more efficient in the long run?" Ideally there would be an open probe into the project as a whole decide whether or not the switch is a good idea, and whether or not such a change should be accomplished with Rust.

bluejekyll 4y ago
This isn’t a simple thing to answer as it’s specific to any given project. If something is millions of lines of code, will anyone ever fund a full rewrite that could take years? In that case finding areas to plug-in Rust is probably the better strategy. See the Linux kernel and drivers being able to be in Rust. On the other hand, if something is only a few thousand lines of code, a rewrite wouldn’t take much time and might be worth it.

andsoitis 4y ago

> so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. How well does Rust inter operate with C or C++ code? When you interoperate, do the security issues persist or do they disappear automagically?

Arnavion 4y ago
There is unsafety at the FFI boundary. The C functions will deal with pointers, so the Rust side will have to use pointers too. The Rust side will normally thunk it into safe Rust (convert pointers to references by introducing lifetimes, wrapping in types with destructors, making sure to add or remove Send / Sync impls as necessary, etc) so that the rest of the Rust code that's not at the boundary can be safe. So if you have a Rust function that receives a pointer and a length representing the array, it will translate that into a Rust slice by trusting the pointer and length. Of course if the C caller gave a garbage pointer or a length that's bigger than the actual C array, then the "safe" Rust code that uses that slice will still be illegal. C++ interop has some additional complexity because of templates, methods, inheritance, etc, that's handled by the cxx Rust library. I don't know much about it.
bluejekyll 4y ago
Rust allows for zero overhead FFI between itself and C. For C++, there are some crates working to make that easier so that C++ objects can be shared, but generally, the C ABI is the common interop layer. As to the security issues persisting, yes, the C security issues will persist. But, what’s nice is that the Rust code is safe and you just need to attest to the compiler that the usage of those C APIs is safe. Essentially the Rust code is safe, but it’s still your responsibility to prove that the C code is safe.