Memory safety is table stakes

Memory safety vs. performance and “table stakes”

• One side argues memory safety cannot be “table stakes” because performance is often the hard, non-negotiable constraint; if memory safety were truly mandatory, existing safe languages would already dominate everywhere.
• Others counter that inertia and culture (“performance at every cost”) slowed adoption of safer languages, and that we’re gradually unlearning this.
• There’s debate over whether performance is actually prioritized in practice, given how many real-world applications are slow and bloated despite being written in “fast” languages.

Rust’s safety model, unsafe, and tooling

• Critics note that Rust has unsafe and claim there’s “effectively no tooling” to audit it, so “if it compiles, it’s correct” is overstated.
• Defenders list multiple tools: Rust lints that can forbid unsafe in a project, cargo-geiger to scan dependencies, and MIRI plus sanitizers (ASAN/UBSAN/MSAN/TSAN) applied to Rust.
• Some argue fully banning unsafe across a large dependency graph is unrealistic because it’s needed for FFI, allocation, and certain data structures; others in safety‑critical work say it’s at least possible to design Rust systems that exclude unsafe, unlike C++.
• Analogy is drawn to trusted kernels in theorem provers and to Python: “safe Rust” can be considered memory safe even if its implementation relies on unsafe.

Adoption, legacy code, and economics

• Commenters stress that most new code globally is already in GC’d memory-safe languages (Java, Python, C#, Go, etc.); the real battleground is OSes, browsers, low-level infrastructure, control/embedded systems, and high‑performance C++ stacks.
• Resistance is often framed as economic: vast C/C++ codebases (browsers, search engines, databases, finance, robotics, defense) are too expensive or risky to rewrite wholesale, even if Rust or others are safer.
• Others push back that rewrites might become cheaper than maintaining brittle C++ over time, and that critical systems with large unsafe surfaces are dangerous “Prince Rupert’s drops.”

Other languages, culture, and history

• Historical safe languages (Lisp, Smalltalk, ML, Ada, Pascal) are cited; one view blames irrational, culture-driven choices (syntax, “cult of speed”) for their limited adoption.
• Another view argues market decisions are mostly rational tradeoffs: older languages often lost on tooling, compiler speed, talent availability, or ergonomics despite safety advantages.

Omniglot and FFI details

• The article’s Omniglot example (safe Rust–C interop) is criticized as contrived; some note existing tools like bindgen already handle certain enum cases correctly, though behavior and defaults are debated.
• There’s some low-level discussion about enum layout (repr(C)), null-termination in FFI, and whether mapping C enums to Rust enums is good design versus using constants.

Usability and perceptions of Rust

• Opinions diverge sharply on Rust’s usability: some find it “very easy” and suitable even for scripting; others see the syntax and borrow checker as major barriers that will prevent mainstream adoption.
• Several commenters observe that discussions about Rust often devolve into polarized claims about difficulty, performance, and marketing rather than nuanced tradeoff analysis.