> Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume.
Microsoft and Google have both reported that memory safety errors make up about 70% of their security vulnerabilities.
Microsoft and Google have both reported that memory safety errors make up about 70% of their security vulnerabilities.
They did not release those numbers.
> Why did Google choose C/C++ for Fuchsia after evaluating also Rust?
A couple of things here:
* We don't actually know if they did evaluate Rust for the kernel or not.
* At the time they would have been making that evaluation, Rust was one year past 1.0, and was significantly less mature than it is now.
* They had a bunch of people who had experience with existing kernels that were in C and C++, and in fact, based Zircon on one of them: LK.
All of these are good reasons to pick what they picked. However, there's one more thing here, and that's that Fuchsia is a microkernel, and so the kernel is a lot smaller than in other OSes. Rust is used for a bunch of components that would be in the kernel if Fuchsia was a monolithic kernel.
> How come, Actix announced a new version with memory leaks fixed?
Well, first of all, memory leaks aren't a memory safety issue, so this would be irrelevant. However, Actix had actual memory safety issues as well, and did fix those. This happened because the author used a lot of unsafe that they didn't need to. This is pretty straightforward though; it was easy to find those issues because of the way that Rust works, and then they were fixed. That's kind of the point!
There are times you need manual memory management. Then there are other times you don't (the vast majority of use cases). Rust forces you to constantly pretend that memory management matters, which gets quickly tiresome.
Not everyone is working on Chromium or Windows. The reality of the matter is that for most real-world software development security doesn't matter at all.