I&#x27;ll take the bet that in 2035 it&#x27;s still going to be C&#x2F;C++ (or a C derivative like Boring C).  Because rewriting all that code is an economic impossibility.  There&#x27;s a very long way to go before the rate of foundational Rust code written exceeds the rate of foundational C&#x2F;C++ code written.  And even if you manage to have 100% Rust and 0% C&#x2F;C++ code being written, you still have a huge legacy to write, which literally costs billions of dollars (ALL operating systems, ALL browsers, ALL interpreters (Python&#x2F;PHP&#x2F;Perl&#x2F;...), ALL compilers (GCC, LLVM), ALL web servers, etc.)<p>Honestly I think your view of technological adoption is fairly naive -- I don&#x27;t see much content here other than &quot;everyone get behind Rust!&quot;.<p>IMO the more realistic approach is a systems approach: make it so that badly written C code doesn&#x27;t completely hose your system.  I like the application compartmentalization work (Chrome style, DJB style), and capability work like Capsicum.  And LangSec work in making safe parsers.  The trusted computing base has to be reduced.  Not every line of C code should run in a trusted context!!!  Principle of least privilege.  We know (or should know) all this stuff.<p>That is many of orders of less magnitude less work &#x2F; cost, and I think actually feasible.  Coherent and secure systems architecture is more achievable than everybody writing perfect C code or everybody switching to another language.<p>Another thing the Rust community should be working on is easy and efficient IPC with C programs.  So you can rewrite a secure core in Rust and communicate with legacy C&#x2F;C++ running in an untrusted OS context.<p>And also fixing the mess that is Linux containers, so it isn&#x27;t so difficult to secure them (i.e. see Docker&#x27;s security issues)