[testdelacc1]

Here, find the “null result” in this study by the Android team - Eliminating Memory Safety Vulnerabilities at the Source (https://security.googleblog.com/2024/09/eliminating-memory-s...). They stopped adding new memory unsafe code and they saw a dramatic drop in the number of memory safety vulnerabilities. They only write new code in Kotlin or Rust now.

The Android team shipped a more secure operating system to billions of people. Their lives are better because of choosing more Rust and Kotlin and less C++.

> You can't write a device driver without manipulating memory directly.

This isn’t the gotcha you think it is. Check out this upstreamed driver - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

This is a successful kernel driver that powers all IPC in Android. This is the most load bearing component in Android, especially because it is constantly being attacked by malware. It manipulates memory just fine actually.

In your hurry to dismiss Rust, you haven’t done a technical evaluation of it. If you had you wouldn’t conflate memory safety with a lack of memory manipulation. You’ve taken the intellectually lazy shortcut of dismissing a new thing because no new thing can be as good as the old things.

I write all this not to convince you to change your mind. I don’t think that’s possible. I write it so anyone else reading this will avoid your thought process. I don’t need to convince you, because this industry is moving ahead regardless.

[hunterpayne]

> If you had you wouldn’t conflate memory safety with a lack of memory manipulation.

We are all aware of unsafe. We are also aware that all those assurances of safety go away in those circumstances.

This is cherry-picking. I didn't say all research papers, just most. This is a very specific circumstance. Under specific circumstances these ideas will work.

This example is one where the replaced code wasn't that old, on a very specific set of hardware and in a rather specific case. Its basically the ideal set of conditions for a rewrite. But there are plenty of cases where attempts to swap in Rust aren't being done in ideal conditions like this. I doubt switching to Rust is never a good idea. I also doubt switching to Rust is always a good idea.

PS The problem is partly the way you write. I criticize ideas. You criticize me. That's a big part of why you get pushback.

[testdelacc1]

> android runs on a very specific set of hardware

How could anyone possibly think this? It runs on ARMv7, ARM64, x86 and x86-64. What else do you want it to run on? It runs on literally billions of devices, made by hundreds of manufacturers - phones, TVs, Chromebooks, cars. All of these couldn’t be more different.

Windows/MacOS are examples of supporting specific hardware. Android works on incredibly diverse hardware. All of which will be powered by Rust now.

> wasn’t that old

Binder is about 20 years old. Linux is 30 years old, by the way. It was developed across 3 different corporations. There’s a reason the code was incredibly difficult to make changes to.

Could we stick to facts, please? This stuff isn’t hard to google.

> I also doubt switching to Rust is always a good idea.

No one said this, by the way. This is a strawman you’ve constructed.

PS the problem is that none of what you write makes sense. No one is giving me any pushback apart from you. And the only way you’re able to pushback is by completely ignoring facts.