Also "for rewriting popular systems in Rust" is just false. The blog is about improving memory safety and gives two pieces of software rewritten in Rust as an example.
There's nothing about this effort being focused on rewriting things in Rust.
You're going to see a lot of Rust, because by and large the programs ISRG and Google are talking about remain in memory-unsafe languages because they have constituencies where dynamic-runtime memory-safe languages are problematic. That's why security people are so excited about Rust: it's hard to come up with modern settings where Rust is unworkable, unlike Go (a language I prefer to Rust), which, for instance, isn't a good fit for the Linux kernel or for the guts of Chromium.
There's a ton of platforms that Rust doesn't not target, or targets but without many guarantees of support. The can be problematic as its closest competitors (C++, but especially C) generally have much more widespread support.
That's a problem, but it's one that's more likely to be worked around (most likely: by maintaining unsafe forks for those platforms) than "creating entire new communities of support for another language" or "redesigning whole projects to make GC tenable".
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).
Oh, I'm not suggesting that they will use Go–they will use C and I'm just responding to you saying that it is difficult to find situations where Rust is unworkable.
The premise of this story is that ISRG is going to secure funding to essentially bribe people (my words, and I think it's a very good project) to not keep critical software in C anymore.
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.
Yeah none of that is going to happen. People aren't going to rewrite major open source projects in Oberon, or specially hosted .NET, or custom JVMs, or Ada. ISRG isn't going to arrange funding for things to be rewritten in another memory-unsafe language, so C++ is right out. Stuff is going to get rewritten in Rust. Sorry!
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).
In what concerns Microsoft, the official security guidelines are .NET, Rust and C++ (with Core Guidelines).
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.
I'm not making a value judgement. I prefer GC'd languages. I'm saying: if they're not GC'd now, when there are multiple excellent choices for managed-runtime languages, it ain't gonna be GC'd. And obviously, it's not going to be C++.
Ok there I agree with you, however in some domains the choice is made by who is calling the shots and not due the technical merits of some sorts.
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.
> 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.
Rust is going to be used often, but we are open to other choices when they make sense.
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.
The quote you provide above doesn't specify that these rewrites are to be in Rust and I don't think you've contradicted the parent in any way. The examples have been in Rust but the foundation doesn't seem to insist on rewrites being done in a specific language. As an aside, the foundation doesn't seem to be much more than a collection of papers at this point.
There's nothing about this effort being focused on rewriting things in Rust.