Some of these issues
> monomorphization
C++ language is equally bad, but there're well-known workarounds. If you don't abuse Alexandrescu-style, using compilation units, have sane architecture without God objects, it's often not too bad.
> macros
Not just any macros, macros who require multiple passes. C macros are single-pass and pretty efficient.
> build scripts
How that applies to C++?
> how many VMs don't have such escape hatches?
Java doesn't. In C# the hatch exists but can be reliably shut.
> its standard library is probably implemented in unsafe code
No, they don't.
http://www.docjar.com/html/api/java/util/ArrayList.java.html
JNI, com.sun.misc.Unsafe, etc
> In C# the hatch exists but can be reliably shut.
P/Invoke?
It's a tradeoff, of course: GC languages let you avoid unsafe code at the cost of doing GCs, which in some applications is an issue. Rust's stroke of genius is that it can avoid GCs while giving you almost all the safety of a GC language.
Overall I think it's safe (no pun intended) to say that Rust is significantly safer than C or C++, but slightly less safe than Java or C#. But of course both of those comparisons have lots of caveats and exceptions. And there are other factors than safety as well.
It's so complicated practically no one uses it.
> P/Invoke?
Can be disabled at VM level. Environments like asp.net classic default to partial trust, this ensures vast majority of third-party libraries aren't using p/invoke nor unsafe.
Most of those issues are either about the compiler (it generates a lot of LLVM IR, it's single-threaded), or apply equally well to C++ (monomorphization, macros, build scripts). Nothing significantly impacting compilation times is fundamental to the language afaict.
> It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost.
True.
> In VM-based languages which don't use unsafe code
Since you've added that qualifier, sure, Rust would be less safe. But how many VMs don't have such escape hatches? JavaScript in the browser is the only one that comes to mind.
> vulnerabilities like this are impossible by design
I find this very hard to believe. Even if your VM has no unsafe code, its standard library is probably implemented in unsafe code, where vulnerabilities like this can definitely happen.