It's not nearly that simple. Look, I get it: you're a fan of Rust. That's great. Use whatever language floats your boat.
But, it takes more than language features to solve security issues. Memory vulnerabilities are only a small piece of the wide range of potential defects that exist in software. These are also defects that largely go away with training and experience.
I can teach most C / C++ developers how to manage memory and pointers in a way that avoids all of the pitfalls that Rust is designed to prevent. It is absolutely possible to write reasonably secure software in most general purpose programming languages. This is true for C, C++, and even Rust. Don't believe me? Spend some time studying the formal proof behind the se implementation of L4, written in C.
All of this being said, I am a big fan of high-level languages. For my personal work, I write 80% of my software in Literate Haskell and around 20% in a lower level language like C++. But, I also understand the limitations that comes with abstraction, and they are big. System level code operates under a lot of constraints, and the abstraction that come with "safe" languages can come at the cost of this code working at all.
A good software engineer uses whichever tool he / she needs to build good software. If the process is followed, then there is no reason why we can't have an ecosystem that uses whichever languages are best for the problem. For most system level stuff, C/C++ are perfectly fine. If you want to use Rust, great. But, don't delude yourself into believing that your language choice trumps good engineering practice. It never will. Don't believe me? Write some software that can work around the Halting Problem in Rust, and get back to me. Because, that's the sort of intelligence you would need in a compiler or a tool to replace good practice.