> (The most obvious example being memory exhaustion: postmortem heap analysis is often much easier on a C-based system than in memory-safe languages.[1])
This is a problem of GC, not of memory safety. Memory safety does not require GC.
> More generally, do not fall into the trap of correctness from smugness: nasty production bugs can exist in any language, and time is much better spent on the production tooling to debug such problems rather than simply asserting that such bugs are tautologically impossible.
The failure modes of the lack of memory safety range from "annoying crash due to null pointer dereference" up to "millions of users at risk of 0-day RCE due to use after free". When the stakes are that high, it's worth spending time to attack those bug classes systematically as opposed to just tackling these bugs in production one-by-one.
Your assertion that "this is a problem of GC, not of memory safety" is incorrect (and I never asserted that GC was the core problem). Memory safety does require a layer of indirection between the native system and the programmer, and that layer introduces opacity to the native system that necessitates its own layer of custom tooling to see through. And memory exhaustion is (obviously!) not a problem restricted to GC'd environments -- any program in any (modern, Turing complete) environment can allocate memory to the point of process death!
> Memory safety does require a layer of indirection between the native system and the programmer, and that layer introduces opacity to the native system that necessitates its own layer of custom tooling to see through.
No, it doesn't. That's literally what Rust (what I worked/work on) is all about. Memory safety is all done at compile time, and it's boiled away to direct access to the platform's native memory subsystem. Platform-native tooling "just works", and I use it every day.
That's terrific, and apologies if you feel I've slighted Rust at all. (I admire Rust's goals to deliver safety without compromising performance or debuggability.) From a native perspective, two things I would love to see with respect to Rust: first, a comment on Alex Light's work[1], as alternative allocators like libumem are often essential for debuggability. Second, I would love to see the applicability of native techniques like postmortem object type identification[2] to Rust. If that "just works" it would be reason alone to seriously evaluate Rust!
No worries, and apologies if I seemed snippy. Thanks for the fascinating link on postmortem object type identification; now I have some reading to do :)
This is a problem of GC, not of memory safety. Memory safety does not require GC.
> More generally, do not fall into the trap of correctness from smugness: nasty production bugs can exist in any language, and time is much better spent on the production tooling to debug such problems rather than simply asserting that such bugs are tautologically impossible.
The failure modes of the lack of memory safety range from "annoying crash due to null pointer dereference" up to "millions of users at risk of 0-day RCE due to use after free". When the stakes are that high, it's worth spending time to attack those bug classes systematically as opposed to just tackling these bugs in production one-by-one.