First lemme reply to the linked objections:
It’s clearly not fast enough if you need unsafe to get real performance - which is the reason this cve was possible.
You don’t need unsafe to get real performance. There are certain structures and actions (eg calling C code) where unsafe is necessary, but this is not equivalents to performance. There are certain situations where you can use unsafe to get better performance than a safe approach, but even the safe performance would be way better than Python or even JS. Going by the computer language benchmarks game, Rust can usually do about as well as C and sometimes better. IIRC this had to be idiomatic and the one program source I looked at didn’t have any use of unsafe.
It’s clearly not preventing segfaults - which this cve shows.
Rust does prevent segfaults. But it does not prevent all segfaults. Especially if you use unsafe. This is like if you buy a cutting tool with a safety guard, and you remove the safety guard for some (even legitimate) reason. The safety guard can still prevent a huge number of injuries.
It also can’t prevent deadlocks so it is not guaranteeing thread safety.
This really depends on what someone means by thread-safe. Often times I hear thread safety being used in the context of data races, which Rust does prevent.
So at a high level I’d only really maybe take exception with the thread safety comment, but it’s such a core part of the language and hard to quantify that I’m not sure there’s a better way to put it.
Two things I don’t see captured very well in that statement are program correctness and refactoring with confidence. However these I would agree that “guarantees” is too strong, but I think Rust offers a confidence in software that is of real value.