| Your point might make sense for web facing software because programs where lives are actually at stake are written in Ada or a subset of C with rigorous static analysis and engineering processes. Now, it can't be denied that C and C++ are weak from a security perspective and that they should be avoided for network software as much as possible. But the problem with your take is the subtle implication that Rust is "safe" (not just memory-safe) when in fact there is no empirical evidence or track record of Rust being successfully used in anything remotely mission-critical. I mention this because you brought up the bridge example when it is also possible that due to language complexity that the new "bridge" built in Rust would turn out to be even fragile (but just memory-safe). Just the other day, there was a Rust GUI library posted here. The library uses a convoluted event handling mechanism of passing enum values as messages and additional book-keeping burden instead of straightforward closures just so that the compiler can prove the code is safe (just memory-safe, mind you). It is possible that because of such contortions required to pass the compiler, Rust could fare worse in the "general correctness" area[1]. It is just that we don't know yet. Even the particular safety issue that is mentioned in the GP comment could be solved by having built-in slice types and mandatory bounds checking (like Zig/Go/D). As usual, C/C++ have terrible defaults. Again, I agree that there is a need for secure alternatives to C and C++. But the contention is whether Rust is that. Even Rust is actually far from optimal in the "safe systems language" space. There might be languages in the future that are as fast as Rust but more ergonomic. Microsoft Research, for example, is creating a research language named Verona[2] that aims to be memory-safe and concurrency-safe. There are also other attempts like Vale[3] that aim at this space. It is premature to think that Rust is the final evolutionary step in the landscape of systems language and suggest for everything to be moved to Rust ASAP. It often appears like reckless fanaticism. [1]: There is, in fact, few "anecdata" of Rust being less reliable:
https://news.ycombinator.com/item?id=24027296
https://dev.to/yujiri8/it-seems-like-rust-software-us-bad-hk... [2]: https://www.microsoft.com/en-us/research/project/project-ver... [3]: https://vale.dev/ |
An application built from the ground up in a language like Rust is going to have fewer vulnerabilities than the same application built in C++. I say this as a person who loves C++ and is intimately familiar with the state of the art of securing C++ applications. I am not proposing an immediate rewrite of everything, though I do personally believe that the "well a rewrite will just introduce more vulns" concern is overblown. I expect papers in ICSE in the not to distant future to be able to validate one of our views.
Rust is not flawless, not even close. There are other alternatives and there can even be new languages in the future, but it has the most mindshare and it is an alternative today. For many years, people would simply say that there was nothing that could compete with C and C++ for systems programming. Rust very nearly handles all of the common use cases. But... I didn't even really mention Rust in my post so I think it is especially difficult to call me an evangelist for it.
Like it or not, ideas in research languages take ages to filter into real world ecosystems. My PhD is in the intersection of static analysis and security. I love this research. But the honest truth is that waiting for MSR to produce the path forward is not a winning strategy. Languages need ecosystems and I think it is more likely that the future will come from industry than directly from academia.