Hacker News Reader

> 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.

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.

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.

> 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?

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.

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.

> While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to eliminate said bugs

A ton of data about software bugs and vulnerabilities, as well as history, seems to disagree with you here.

I suppose in the most permissive use of the term "can", sure you "can" eliminate all those bugs in C/C++ code bases, but at what cost? Formal verification? A code review process that has requirements similar to those imposed on people working on spaceship and airliner avionics software? That's impractical for the vast majority of projects.

It just seems more sensible to use a language that eliminates certain classes of bugs entirely. Rust does that, at least for some classes of bugs. I'll grant you that maybe Rust isn't the correct answer here, but C (and even C++) IMO need to be relegated to the past.

I recently got re-involved in a C-based open source project that I used to work on ~15 years ago. In the intervening time, most of my work has been done using JVM languages, and, more recently, Rust. Going back to C has been tedious and error-prone. The language is awkward to use, and its type system is a joke. I would absolutely love to be able to work in Rust instead, or... really, anything else.

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them?

Neither, and that's not what the article in question is proposing doing.

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them?

One thing you're missing is that "comb[ing] through the currently existing code manually" doesn't help you in the future. Unless you have an absolute code freeze new code keeps getting written which can (depending on the language) affect the correctness of distant already reviewed code. So even if you can absolutely ensure that the code as it exists today is perfect (which is already an exceedingly thing to do), you need to keep that effort up continuously, lest a code change causes prior invariants to no longer be met.

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them?

This is for the NVK project, which is creating an open source GPU driver for NVIDIA GPUs. The project has a number of considerations that are not in the blog post:

> The unfortunate reality is that, while the original nouveau drivers were written by some amazing engineers and were state-of-the-art a decade ago, they have fallen behind in the last several years. The few developer hours it gets are mostly spent on basic hardware enablement and trying to get new OpenGL versions, leaving the systemic and architectural issues unaddressed.

You can find more complete rationale in their announcement blog post, and it seems very thoughtful: https://www.collabora.com/news-and-blog/news-and-events/intr...

If you want Yet Another Example of using Rust to write GPU drivers, you can look at the other Mesa driver in development (for the Apple AGX GPUs): https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ (see "Rust is magical!")

The sibling comments have good points, but the actual reality is that any project that wants to stay alive and attract new developers in 10 years should probably start introducing Rust about now. Linus to his credit picked up on that.