I'd like to also nominate the full quote from the same source:
Panic is the car automatically pulling over to the side of the road, shutting down the engine, and refusing to restart when the blood-alchohol monitor detects that the driver is intoxicated and undefined behavior is letting things continue until the driver "crashes" into a bunch of school children in a cross-walk.
None of [Rust's] "safe" behaviors can lead to truly undefined behavior. ... If an attacker can only crash or deadlock your program, that's still bad, but it usually can't escalate into Front Page of the New York Times levels of bad.
Another one from the same thread, qualifying Rust's safety
[It is] not only the systems programming problems that Rust tackles and makes accessible, but also the particular intersection of different expertises and goals - the systems problems, the type theoretical approach, the commitment to an accessible user experience - that [makes] Rust a fulcrum of learning for me. Even as my knowledge grows, there [is] always a more informed person - often a world class expert - available to answer my questions.
I’ve been very fortunate over these past 4 years to have had the opportunity to become more and more involved in Rust, to the point that now it is my full time employment. It makes me so glad to hear that my work has had for others the impact that the work of others before had on me.
In Rust there are entire classes of bugs that are simply impossible to create because of the compile time guarantees. Because it’s software, there will be bugs. Oh yes, there will be bugs. However, we can create all new bugs and not trip over these other ones that we’ve been creating for the last four-plus decades.
This is the payoff, and despite the strictness of the compiler, Rust’s bet is that if you learn the way you can be as productive (or more) than with another language. In Programming Rust, Jim Blandy and Jason Orendorff refer to this as “Rust’s radical wager.”
I'm batch-processing thousands of high-resolution TIFF images so these are processes that I start at the end of the day and let run overnight. I have multiple Java implementations that can do this; none of them perform at the same level as my novice Rust implementations.
The security barrier must be earlier. It will make everything easier to secure. By analogy, it’s like securing your own house. You can lock points of entry to your house, and it’ll work fine for the entire house. But if you move the security barrier to wrong place because you assume burglars may freely roam inside your house, you’ll end up with locks on your bathroom, padlocks on your drawers, gates on your bed, TV stored in a safe, and kitchen utensils chained to walls.
Here, your OS is your house. If you work with assumption that you let malware in, and running viruses is normal part of Rust development, you’ll need extraordinary level of sandboxing paranoia similar to having things in your house chained to walls. It’s going to be incredibly hard to secure everything, and it’s going to be incredibly inconvenient to use the language that has to act at all times as if all your code was infected and dangerous.
A better approach is to make sure that there's no path from the guest bedroom to the master bath. That means an OS should not be a monolithic whole, where penetrating any component gives full access to everything. For example, there is no reason why a network interface needs access to the file system, but that's exactly what an exploit from a couple of years ago used. What we need is isolation among the components of the OS. CapRos and seL4 are examples of how it can be done by applying the Principle of Least Privilege at a finer level of granularity than the whole OS.
[Rust's] unique selling point is that it unlocks a level of performance and flexibility that was previously not possible without investing in deep platform-specific knowledge and expensive quality assurance processes.
People aren't kidding when they say Rust gives you superpowers. We spend more money on log storage than all of our servers combined. We can process so many requests [that] we have to spend more to store the logs from those requests than it costs us to actually process them.