The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.
The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.
Another idea is that a software can have a great design but still be full of security holes. C allows for that.
If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
The only thing that will actually prevent security holes is attentive software engineers deliberately choosing to learn tools and practice habits to avoid security holes by design. The professional judgement of a lot of those engineers is leading them to choose to learn rust right now.
Absolutely. It's just that statistically the memory safety bugs have been the dominant percent of all the bugs, so rewriting core tools in a memory-safe language does make sense.
Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs.
Beautifully articulated.
No. But it will make sure there are no issues of the type buffer overflow and such.
The rest, we can judge when the software is delivered.
https://www.cvedetails.com/vulnerability-list/vendor_id-1902...
I'm not so sure....
And those are bugs from from people writing core stuff, like you know, the people who should know Rust better than you and me. People writing foundational code that your program will run on top of.
Of special danger is the last CVE, that was rushed and backported into the last release. But nobody talks about it. I can imagine why.
I can bet that the "but the bug happened within unsafe code" excuse will be the next Rust meme.