It&#x27;s very easy to beat up on vulnerable code and say it&#x27;s &quot;bad C++&quot;, but it&#x27;s also irrelevant. Of course it was bad C++: it was vulnerable code. The problem is empirical and practical. In practice, nobody has managed to scale large C++ codebases up to hundreds of developers without introducing vulnerabilities. You&#x27;re essentially telling Google &quot;just hire better programmers&quot;. That hasn&#x27;t worked for decades, and it&#x27;s not going to start working now.<p>The idea of Rust in this regard is quite simple and obvious. Instead of trying to hire better programmers, just have the computer check to make sure these vulnerabilities don&#x27;t happen. In contrast to the &quot;just hire better programmers&quot; suggestion, which has failed again and again for decades, this works very well in practice, as memory-safe languages have shown.<p>At the end of the day, yes, it&#x27;s theoretically possible to hire hundreds of great programmers who always write perfect C++ with no memory safety problems or undefined behavior. But in practice it never works. Google is in fact in a better position than perhaps any other organization to do this; if it could possibly work for anybody, it surely would have worked for Google!<p>Rust is a choice grounded in pragmatism. Memory safety enforced by the compiler is the only way that we know of to scale up programs to large codebases with hundreds of programmers without introducing mistakes. &quot;Hire better programmers&quot; may work in theory. In practice, it has been tried again and again and has always failed.<p>(Also, std::set is not memory safe. It is vulnerable to UAF due to iterator invalidation: iterate over a set and remove elements, for example.)