Can someone please fix the title to the original in the blog ('Mitigating Memory Safety Issues in Open Source Software'), because the current title is not at all representative of what the blog is actually saying.
There's nothing about this effort being focused on rewriting things in Rust.
> That’s why we’re expanding our collaboration with the Internet Security Research Group to support the reimplementation of critical open-source software in memory-safe languages.
Though the rest of the article doesn't go into detail about this effort beyond http/TLS libs for curl.
Since most unsafe code is C or C++, Rust usually makes the most sense for rewriting one component at a time. It integrates with C and C++ very cleanly because it has good FFI and no runtime.
If we were rewriting more projects from scratch and integration with existing C and C++ code was not important, we might use other languages more often. I don't expect we'll attempt to rewrite many pieces of software from scratch.
Source: I run the memory safety initiative at ISRG.
I think you might see some full-system rewrites for serverside components where Go will work out. But I think the projects we're talking about, like I said, have ended up in this position mostly because they can't easily be written in Go, or they already would have been (if only be a competitor).
My guess is what will happen in the cases where Rust is unworkable is that there will be less-secure forks for the obscure platforms.
F-Secure has been using TamaGo for bare metal on their secure USB keys.
MeadowLabs is using .NET with a tiny C++ hardware glue for IoT.
Aicas and PTC are still in business delivering real time bare metal Java stacks.
Astrobe is still in business selling Oberon compilers for embedded development.
MikroElektronika is still in business selling Pascal and Basic compilers for embedded development.
And then there are those 5 surviving Ada compiler vendors, one of them open source.
Finally, if there is no way around having to use C, there is no reason not to use C++ instead other that anti-C++ hater religion.
Unless we are talking about UNIX clones, thanks to them C will still be around for several decades to come anyway.
That sounds snarky, I know. I promise, I'm not being snarky, and, again: it ain't my first choice (it'll be fine though).
As for the other platforms, and what Google is paying for, lets see where the bribe drives people into, after all from your point of view Google should rewrite gVisor and everything k8s as well.
Yes it definitely will, but not only, specially among groups where not using a GC is more of a religious issue than an actual technical impediment.
Windows is a good example of this politics game actually.
Joe Duffy mentioned on his Rustconf keynote that even with the system running in production, the Windows team couldn't be argued against.
A system that even powered parts of Asian Bing infrastructure.
Likewise they clearly sabotaged the Longhorn efforts, to replace them with COM, and yet UWP, mostly written in C++, happens to usually run slower than traditional .NET applications on Win32, or any other compiled GC'd language on Windows for that matter.
Edit: the submission title is fixed.