I fundamentally disagree with the sentiment in this article. Rust does not have a culture of "move fast and break things", if anything it suffers from the opposite problem where language additions for things like const generics or async can take a long time to be stabilized because once they are they can't be changed. This is also why the standard library is so small, since it is subject to the same stability requirments as the language once something gets added to the standard library it can't be removed unless it is unsound.
Rust does have one current implementation, but there are efforts to get another one written in C added to GCC. There is also mrustc which is written in C++ and does not have a dependency on LLVM and can be very useful in bootstrapping rustc anywhere that has a C++ compiler.
I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms. The only potential execption I can think of is the BSDs but FreeBSD and NetBSD have T2 support which means that Rust will have a build for these platforms, they just might be buggy. If anyone wants to put in the work to make sure these builds are not buggy and make features work for them the Rust team will gladly bump them up to T1. However, I don't think it is worth putting in the effort for the other platforms mentioned in the blog post. How many people are using POWER9? Can you even buy a useable RISCV machine at the moment? If and when these architectures start being widely used I'm sure there will be somebody willing to port Rust to them, however until then it would be wasted effort.
I'm not going to argue that a formally verified C program is going to be worse than a Rust program, let alone that writing a program in Rust will instantly solve every security problem you have, but considuring how many memory safety bugs regularly cause security issues I think that writing new programs in Rust and putting the effort in to carefully rewrite C/C++ programs into Rust is a net benifit to security and certainly better than starting a new project in C or C++.
Rust does have one current implementation, but there are efforts to get another one written in C added to GCC. There is also mrustc which is written in C++ and does not have a dependency on LLVM and can be very useful in bootstrapping rustc anywhere that has a C++ compiler.
I also personally don't think that Rust only having T1 support for Windows, Mac, and Linux on x86 and Arm is a problem, everything else is practically non-existant when compared to these platforms. The only potential execption I can think of is the BSDs but FreeBSD and NetBSD have T2 support which means that Rust will have a build for these platforms, they just might be buggy. If anyone wants to put in the work to make sure these builds are not buggy and make features work for them the Rust team will gladly bump them up to T1. However, I don't think it is worth putting in the effort for the other platforms mentioned in the blog post. How many people are using POWER9? Can you even buy a useable RISCV machine at the moment? If and when these architectures start being widely used I'm sure there will be somebody willing to port Rust to them, however until then it would be wasted effort.
I'm not going to argue that a formally verified C program is going to be worse than a Rust program, let alone that writing a program in Rust will instantly solve every security problem you have, but considuring how many memory safety bugs regularly cause security issues I think that writing new programs in Rust and putting the effort in to carefully rewrite C/C++ programs into Rust is a net benifit to security and certainly better than starting a new project in C or C++.