It might not be a magic security wand, but so many critical vulnerabilities in software trace their origins to memory unsafe code and things like "use after free".

"~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" - Microsoft [1]

"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code." - Google on Android [2]

This is also worth looking: https://www.chromium.org/Home/chromium-security/memory-safet...

References: 1. https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactiv... 2. https://blog.google/security/rust-in-android-move-fast-fix-t...

It kind of is, as is any other memory safe language.

You certainly can still write security vulnerabilities that don't involve memory safety violations, and these languages always have unsafe escape hatches that you can use to shoot yourself in the foot. But as long as you don't just sprinkle unsafe on everything, using a safer language is going to make a ton of vulnerabilities just disappear.

Looking at the issues from this past week, safe languages won't stop you from using 4 as your private key, but they would have entirely prevented the PHP vulnerability.

No, but it was created to mitigate these sorts of risks.

It cuts down most of the crap trying to trash your machine's RAM (virtual memory in the end, but today it's almost as if you didn't have a MMU). It's good enough.

On less powerful machines, dear Mutt+isync+msmtp users like me, please use AERC (written in Go) against these. It's slower, but far more secure than C. Also, SLRN needs a Go rewritten clone (able to point to slrn's caché) like nothing else. Comp.misc and comp.arch still are extremely valuable.