I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java.
For instance:
Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callback pattern, not swing).
Java serialization surfaces all sorts of private methods to outside processes via the reflection APIs, which is even easier to exploit than arbitrary memory stomping in C.
Practically everything can throw a null pointer exception, and all generics code can throw ClassCastExceptions. Writing all the error handling logic for this is at least as hard as restricting yourself to a memory-safe subset of C++ templates. If you miss an error handling case, an attacker can use that to escalate up to increasingly high level invariant violations in your code.
Basic things like “final” have ill-defined semantics with multithreaded code (final fields can change value, even without reflection).
I don’t know Rust well enough to know which classes of these bugs it has (and I doubt the Rust community really does either—-it took the Java world a decade to notice some issues like the above).
With the exception of the “final” problems, I think fixing any of the things I listed reduces to solving the halting problem, or giving up on using turing complete languages.
This makes me skeptical of many claims coming from Rust proponents at the moment.