Memory safety is table stakes

This discussion revolves around the adoption of memory-safe languages, with a particular focus on Rust, and its comparison to established languages like C++.

The Role and Perception of unsafe in Rust

A central theme is the management and perception of the unsafe keyword in Rust. While some argue that its presence fundamentally undermines Rust's memory safety guarantees, others contend that Rust provides robust tooling and language features to manage and audit unsafe code effectively.

• "In a language with the unsafe construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance." - timewizard
• "You can forbid using unsafe code with the lints built into rustc: [link to rustc lint documentation]" - AlotOfReading
• "All of this is worlds ahead of the situation in C++." - AlotOfReading
• "All the C++ tooling that I'm aware of (e.g. ASAN/UBSAN/MSAN/TSAN) is still available on Rust. Additionally, it has MIRI which can check certain code constructs for defined behavior at the MIR level... C/C++ doesn't have anything like that for undefined behavior by the way." - vlovich123
• "However, if I can apply a nitpicking attitude here... unsafe is pretty baked into the language because there's either simply convenient constructs that the Rust compiler can't ever prove safely... or is required for basic operations (e.g. allocating memory). Pretending like you can really forbid unsafe code wholesale in your dependency chain is not practical..." - vlovich123
• "Safe rust is a safe language. Yes, it is built upon unsafe rust. But I still consider Python to be a memory safe language despite it being built on C. I can still trust that my Python code doesn't contain such memory errors. Safe Rust is the same in terms of guarantees. That's all that anyone is claiming." - xvedejas
• "Languages with unsafe don't just change where the security boundary lies. It shrinks the size of the area that the boundary surrounds." - zaphar
• "c/c++ you're in unsafe mode by default, unless you build guardrails yourself. rust built different: unsafe is loud, compiler flags it, tooling keeps count, you can gate it in ci. bugs don’t slip in quiet.. burden of proof shifts" - b0a04gl

Performance as a Key Driver and the "Performance at Any Cost" Mentality

The discussion touches upon the historical emphasis on performance and how it has hindered the adoption of safer alternatives. It's suggested that performance remains a crucial, if not the primary, consideration for many projects, and that the shift towards memory safety is a slow cultural and technical process.

• "Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes." - timewizard
• "I think a big part of it is just inertia." - noisem4ker
• "It's been a very slow learning process trying to undo the "performance at every cost" mantra." - dwattttt

C++'s Legacy and Limitations in Memory Safety

The conversation frequently contrasts Rust with C++, highlighting C++'s strengths in ecosystem and backwards compatibility, but also its inherent challenges in achieving robust memory safety due to its historical design decisions.

• "Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down." - timewizard
• "All of this is worlds ahead of the situation in C++." - AlotOfReading
• "C++ has artificially limited how much it can improve the memory safety picture because of their quite valid dedication to backwards compatibility. This is a totally valid choice on their part but it does mean that C++ is largely out of the running for the kinds of table stakes memory safety stuff the article talks about." - zaphar

The Broader Landscape of Memory-Safe Languages and Rust's Position

The discussion acknowledges the existence of numerous memory-safe languages and frames Rust's success within this broader context. Rust is seen as benefiting from past research and development in memory safety, coupled with effective advocacy.

• "There are dozens of memory safe languages that already exist: Java, Go, Python, C#, Rust, ..." - zaphar
• "If Rust is the language that finally overwhelms the resistance to memory safe languages, that's good. I think it's also important not to centre Rust alone. In the larger picture, Rust has a combo of A) good timing, and B) the best evangelism. It stands on decades of memory safe language & runtime development, as well as the efforts of their many advocates." - nick_
• "I think it's important to keep the scope of the debate well-defined, because memory-safe languages completely stomped out memory-unsafe languages more than 20 years ago; almost all new code is written in languages that are unshowily memory safe (like Java and Python). We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems." - tptacek
• "Rust also didn't give up, whereas earlier languages like Cyclone did. This is a problem with the different incentives in research; once you've shown it works there is no funding for further development." - noelwelsh

Quantifiable Improvements and Industry Adoption

There's a reference to external evidence demonstrating the practical benefits of using Rust, specifically Google's shift to Rust leading to quantifiable improvements.

• "Industry is seeing quantifiable improvements, eg: [link to Google's shift to Rust article]" - imglorp

Concerns about Vendor Lock-in and Language Longevity

One user raises a point about the potential impermanence of proprietary languages, contrasting them with languages that might have broader, more distributed implementations.

• "All of the languages you listed are proprietary languages. Most of them have a single implementation. They could disappear tomorrow. While that's unlikely, it's a possibility that some will go the way of ColdFusion, and more will fade away like Pascal." - torstenvl

Critique of Specific bindgen Behavior

Finally, a minor point is raised regarding the behavior of bindgen in relation to C enums, suggesting a potential area for improvement in how such constructs are handled for Rust.

• "What they're saying is kind of true, but the example is very bad. bindgen already doesn't generate Rust enums for C enums exactly for this reason. It insteads generates const's with each variant's value, and the enum type is just an alias to its basic type (i32 or something else). This forces you to do a match on an integer, where you have to treat the _ case (with unreachable!() probably). I can't tell if this is the whole paper, but it seems low effort at best." - xTachyon