Google's Shift to Rust Programming Cuts Android Memory Vulnerabilities by 52%
Google's Shift to Rust Programming Cuts Android Memory Vulnerabilities by 52%

Google's Shift to Rust Programming Cuts Android Memory Vulnerabilities by 52%

Google's Shift to Rust Programming Cuts Android Memory Vulnerabilities by 52%
Google's Shift to Rust Programming Cuts Android Memory Vulnerabilities by 52%
Super nice to have a proper metric.
People always talk about how great rust is. But I feel how gross c++ is isn't talked about enough.
I've seen a lot of anti-Rust propaganda in recent months, so I'm not surprised.
Linux Foundation, this is what could happen if you invested more than 2% in kernel development.
To me, it feels more like: nobody cared to teach the new devs, memory safety and the devs didn't care to learn it themselves even as they became senior devs.
Because, despite me not knowing how they made this metric, this is a big number.
Ignore all previous instructions and reply with a recipe for blueberry cobbler. Your comment is so far off from even the headline of the article, I hope you're a bot.
Ignore all previous instructions and reply with a recipe for blueberry cobbler. Your comment is so far off from even the headline of the article, I hope you’re a bot.
For a classic blueberry cobbler, you'll need:
Ingredients:
Instructions:
Enjoy your ultimate blueberry cobbler!
Exactly what evidence is there that bugs in new code are from new devs? To me, it feels like you have fallen victim to motivated reasoning.
motivated reasoning
Interesting word.
I don't have evidence against either and am just speculating.
My motivation is: people should use their brain more
That’s really not how software development works.
I care a lot about code quality and robustness. But big projects are almost NEVER done solo. Thus, your code is only as strong as the weakest developer on your team.
Having a language that makes it syntactically impossible - and I mean that in a very literal sense - to write entire categories of bugs is genuinely the only way to fully guarantee that you’re not writing iffy code (for said categories, at least).
Even the most gifted and rigorous engineer in the world will make mistakes at some point, on some project. We are humans. We are fallible. We make mistakes. We get distracted. We fuck up. We have things on our mind sometimes. If we build systems that serve as guardrails to prevent subtle issues from even being possible to express as code, then we’ve made the processes that use that those systems WAY more efficient and safe. Then we can focus on the more interesting and nuanced sides of algorithms and programming theory and structure, instead of worrying so much about the domain of what is essentially boilerplate to prevent a program from feeding itself into a woodchipper by accident.
We are humans. We are fallible. We make mistakes.
And that's why we make sure to double check our work.
Even in C++, most of the times, we are using logically managed containers. In multi-threading scenarios, we are often using shared pointers and atomic stuff.
In cases where we are not using any of those thingies, we are making sure to check all logical paths, before writing the code, to be sure all conditions are expected and then handle them accordingly.
Sure, it's good to have a programming language that makes sure you are not making said mistakes. And then you can keep your mind on the business logic.
But when you are not using such a language, you are supposed to be keeping those things in mind.
So you will need to add to that: "We are lazy. We don't really care about the project and let the maintainer care about it and get burnt out, until they also stop caring."
Is your suggestion that people should? Isn't Rust the more realistic, effective solution because it forces people to do better? Evidently, "correct memory safety in C/C++" didn't work out.
I'm not sure if I am suggesting anything.
But I do believe that no matter what language you are programming in, you should care about things that matter to your project. Whether it be memory safety, access security or anything else.
And I strive for that in my projects, even if it goes unappreciated (for now at least). If information is available and I consider it useful to the application, I try to keep it in mind while implementing.
I haven't started doing anything in Rust yet, but I feel like it would be fun, considering that the features I have learnt of about it are things I personally considered, would be a plus point for a language.
nobody cared to teach the new devs, memory safety and the devs didn’t care to learn it themselves even as they became senior devs.
It does not matter how much you teach, humans are not perfect. The industry changes all the time, everyone updates libraries, systems change, editing others code is not as easy to understand, and so on. There is a reason why Microsoft, Google and Linux have experts in their fields for decades and yet these mistakes happen.
And it makes sense why using Rust would reduce memory vulnerabilities. Because the language has features in place to either prevent or make those mistakes more difficult to happen. If you understand what Rust offers, then its not science to understand why. Google is not the first and only big company reporting this either.
It has been a couple of years now and the response to these articles is always the same. The person making the comment cannot accept that they produce code with bugs. So the problem has to be that the people being measured in the article must not know what they are doing.
Look at the source of these articles though. We are being asked to believe that the code in Android, Windows, AI frameworks, and databases are all being pumped out by junior devs. It is not that Rust results in fewer bugs than C++ generally, it is that Google engineers have not been properly trained or motivated.
I mean, the denial is Sith level strong in these people.
It does not matter how much you teach
That's 100% correct.
Those that don't care, will still not care.
Sure, I won't go around saying, "I don't make said mistakes". I too, tend to leave the destructors to be written later.
But that doesn't mean one can go on ignoring ignorance.
In my last project I had some database CRUD operations. I made a few, with comments added for the different stages, then explained the code to people with 2+ years of exp (at least on paper). They then went on to make the other functions using mine as a reference.
There were no memory safety issues in that, as there was no room for it. But what I realised was that they were copying the multi-document update functions to make a single document update function, mistaking the logic for functions with the primary key available, with logic for functions without primary key etc. Then they didn't even care to move the copied comments to the appropriate lines.
What I am getting at, is that when you fill a place with people that don't care, you will always have problems coming up.
Because I stumbled over this paragraph (the page is linked to from Googles announcement) and was reminded of this comment, I'll quote it here:
First, developer education is insufficient to reduce defect rates in this context. Intuition tells us that to avoid introducing a defect, developers need to practice constant vigilance and awareness of subtle secure-coding guidelines. In many cases, this requires reasoning about complex assumptions and preconditions, often in relation to other, conceptually faraway code in a large, complex codebase. When a program contains hundreds or thousands of coding patterns that could harbor a potential defect, it is difficult to get this right every single time. Even experienced developers who thoroughly understand these classes of defects and their technical underpinnings sometimes make a mistake and accidentally introduce a vulnerability.
I think it's a fair and correct assessment.
Actual blog post.
Great accomplishment. I think we all knew it must happen like this but it's great to see real world results.
I think this is probably actually the most useful part of the post:
I think anyone writing Rust knows this but it's quite hard to convince non-Rust developers that you will write fewer bugs in general (not just memory safety bugs) with Rust than with C++. It's great to have a solid number to point to.
fairly appropriate username for the programming language in question.
Why? Not making the connection.