3 ms·
It’s nuanced. Google has shown that legacy C/C++ code is fairly stable in terms of memory safety bugs. That and the effort and risks involved means that existin
by faitswulff 2y ago
It’s nuanced. Google has shown that legacy C/C++ code is fairly stable in terms of memory safety bugs. That and the effort and risks involved means that existing C/C++ code is unlikely to be replaced wholesale. But that also means that switching new development to Rust has an outsized effect on preventing new bugs. So expect old code to stick around, but new code to be written in Rust with interoperability with the old code.
- pan69 2y agoThe way I read the parent comment was as in; replacing C/C++ with Rust as a choice for language going forward, not replacing existing C/C++ code bases with Rust.
- deleted 2y ago[deleted]
- faitswulff 2y agoThat’s fair, I think I might have been interpreting it as a call to “rewrite it in rust.”
- p_ing 2y agoIn the video, Mark talks about Microsoft investing in replacing certain portions of Windows/Office/Azure going C/C++/C# [eliminate GC, SharePoint being mentioned] with Rust. Primarily in security-critical areas, but one of the first points in Windows was font handling, a huge security issue for Windows historically.
- jcranmer 2y agoThere are definitely some regions of existing code where legitimately replacing the existing C/C++ functions with Rust is justifiable on its own. The big one I can think of is parsing code--things like parsing fonts (as sibling mentions) or A/V codecs are things that have historically been replete with exploitable memory safety issues and are reliably untrusted data.
- csdreamer7 2y agoThreading is another case. The Asahi's gpu Tust driver was able to avoid a lot of threading issues because of Rust.