> And it's independent of whether a language is GC'd or not; to provide memory safety means to provide a layer of indirection between the system's notion of memory and that of the run-time -- and that layer becomes opaque to traditional native tools.
No! You can enforce memory safety at compile time and use the platform's native memory allocation subsystem. There's no need for memory safety to imply any extra runtime support.
As far as I can tell you're right in principle, but even Rust doesn't currently deliver that in practice. With Rust 1.0, at least on Linux, Rust uses its own bundled jemalloc rather than the libc malloc. So IIUC, that means that you can't take advantage of things like libumem, the alternative malloc described in the blog post bcantrill referenced a few comments ago.
Yeah, I figured someone would bring up jemalloc. :) As of a few days ago, Rust allocation is pluggable [1]. jemalloc is considered a "feature" in the Cargo sense which can be turned on and off. (The immediate impetus for this feature work was to use HeapAlloc() on Windows.)
No! You can enforce memory safety at compile time and use the platform's native memory allocation subsystem. There's no need for memory safety to imply any extra runtime support.