I understand why people want to rewrite C libraries and such in Rust.<p>Software like glibc is battle-tested---it is _widely_ used on hundreds of thousands of systems around the world, and has been used (though not at today&#x27;s massive scale) for decades.  I understand that glibc is under active development and there is a lot of new code, but let&#x27;s keep this in perspective:<p>Writing a new implementation of a system is a huge opportunity to introduce bugs.  There is focus on these specific problems, but in the broader scheme of things, glibc is remarkably stable, performant, and feature-rich.  A new implementation will have bugs, and those bugs might be less likely to be caught simply because the system will not be as widely used for quite a long time.  Even formally proven systems don&#x27;t address flaws in the actual program specification.  (See &quot;The Limits of Correctness&quot; by Brian Cantwell Smith for a good discussion).  Also relevant (which I&#x27;m reminded of in part because of his recent death): Peter Naur&#x27;s Programming as Theory Building.<p>So even _new_ code to glibc has the benefit of a huge community of both developers are users to eyeball it and test it out in production on a huge number of systems.<p>So rewriting glibc may solve certain problems, but it&#x27;s bound to create a whole lot more, considering the narrow range of issues that are being focused on.  New Rust code will have undiscovered issues too, even if they&#x27;re not memory or stack related.  I feel that this effort might be better spent fixing and finding problems with glibc---and continuing the development of tools to find those problems, to benefit _all_ of our old C libraries and programs---than rewriting for the sake of rewriting.