Comment by thesuperbigfrog | Hacker News Reader

Comment by thesuperbigfrog | Hacker News Reader

thesuperbigfrog

"Advice to software developers and open source maintainers who may be thinking about the transition to memory safe code:"

"First, he advises that developers stop creating more unsafe code by writing new projects in memory unsafe languages" ...

"Second, he says, not everything needs to be rewritten at once. Focus first on security-critical modules."

"Third, he says, open source maintainers don't necessarily need to learn Rust to help with the memory safety transition because many Rust-based modules come with C APIs."

"Finally, he argues that the open source community should understand that the current status quo – an endless parade of memory errors – does not have to continue."

I disagree with point 3. Knowing Rust is key because it is being used to replace C and C++ in performance-critical and low-level applications to ensure memory safety. It has the most momentum and is getting inroads in the Linux kernel, the Chrome web browser and its derivatives, and other places.

C and C++ were great because they were initially simple and let us build fast infrastructure with minimal fuss. They will be with us for years to come as legacy languages. Rust is the present and future because it gives the speed of C and C++ without the recklessness of undefined behavior and "do whatever you want" resource management. It is a choice to embrace a bit more discipline and upfront fuss in exchange for memory safety and data race safety.

I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it.

From your example, the idea of porting existing C and C++ code in the kernel or Chrome that has been stable in production for years, or sometimes decades, to Rust. The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust?

I don't know the answer. Because I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code. But I do think too many people are discussing rewrites at scale with the justification of memory safety, without considering the risk the nature of a rewrite adds back.

>> I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it.

You are correct. Rewriting working code is a risk, especially for stable, mature projects.

The "panacea-like degree" is probably due to the refreshment, relief, and liberation that developers feel when working in a memory safe environment. When an estimated 70% of errors are due to memory safety issues, the excitement that developers feel is palpable.

>> The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust?

The risks are real and vary on a per-project basis. I think it depends on the needs and expectations of the project.

For example, a mature project that is not adding new features and is not in a critical role or likely to be targetted for security exploitation probably does not need to be changed.

Other projects under active development or in more critical roles may need to be partially rewritten to protect sensitive functionality (e.g. network handling code, input handling, parsers, etc.)

New projects should choose memory safe languages unless there is simply no other option.

>> I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code.

Sometimes we don't fully understand the problems until we start writing code. It is part of the nature of software development.

I'm always amazed that people ignore vast ecosystems of libraries on which big systems are built. Libraries and frameworks are not static, and the FFI to (or from) rust is almost always a secondary concern to the developers.

I'm in robotics: A field that absolutely fits the Rust paradigm of safety critical, performance-oriented, and (at least somewhat) progressive (being willing to adopt new things to succeed). And yet Rust is absolutely nowhere to be found in real systems, mostly, I believe, because C++ libraries and frameworks dominate everything and are the foundations on which systems are prototyped and built. These systems are supported by large cloud simulation and metrics frameworks, which are of course built with Python and Javascript.

>> Rust is absolutely nowhere to be found in real systems, mostly, I believe, because C++ libraries and frameworks dominate everything and are the foundations on which systems are prototyped and built.

Industry practices do not change overnight.

Legacy code written in Fortran and COBOL is still in use today. Some of the legacy code we use may not be rewritten. That is fine.

If the benefits outweigh the risks, new code will be written in Rust or another memory safe language.

While I agree with the sentiment of 2, there is a gap here: a lot of low-level Rust code is necessarily unsafe. In some areas, rewriting in Rust provides margin benefit - an unsafe block is little better than C, for example. We should be searching for targets that are not only critical, but not necessarily unsafe. That being said, any amount of unsafe that can be prevented is better than none.

Reply on news.ycombinator.com