> as if there isn't any other memory safe language.
But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.
This is not a theoretical exercise. https://materialize.com/blog/rust-concurrency-bug-unbounded-... .
AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.
And even for memory-unsafe languages like Rust, there are trade-offs.
What definition of memory safety are you using where (supposed) "necessity" and "prevalence" are factors, and at what thresholds for those two factors do languages cross from unsafe to safe or vice versa?
> In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
So you have Rust, which uses unsafe code for performant collections, and Java, which uses unsafe code via its JIT for performant collections. I'm not sure I see a substantial difference here.
Everything else aside, why is no_std included here?
And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of constraints relative to resources or bugged infinite recursive calls without tail-call optimization, can do it.
I think you're technically correct, though I also think the picture is a bit more complicated than you paint it. From my understanding, stack overflow protection needs cooperation between (at least) a language, its runtime (if present), and the environment the program is run in. In other words, I'm not sure any language can "protect the stack completely" without knowledge of the environment it's going to be run in, so at least technically speaking I don't think Rust is any different here.
That being said, rustc will insert stack probes even when compiling with no_std, so in environments where stack probes are sufficient to protect against stack overflow/stack clashes no_std is safe with respect to that particular issue.
For example, this short program:
#![no_std]
#[inline(never)]
pub fn f() -> u8 {
let v: [u8; 16384] = [1; 16384];
v.iter().sum()
}
example::f::hb88315ca0b28f303:
sub rsp, 4096
mov qword ptr [rsp], 0
sub rsp, 4096
mov qword ptr [rsp], 0
sub rsp, 4096
mov qword ptr [rsp], 0
sub rsp, 4096
mov qword ptr [rsp], 0
push rax
lea rdi, [rsp + 8]
mov edx, 16384
mov esi, 1
call qword ptr [rip + memset@GOTPCREL]
<further assembly omitted>