[testdelacc1]

> not the same as having a hostile community

Hostile according to who? According to the haters, maybe. I’m sure the Go community was called “hostile” by haters back in the day.

Look at the drama created by Linux maintainers who were being insanely hostile, coming up with spurious objections, being absolute asshats - to the point where even Linus said enough was enough. The Rust for Linux members conducted themselves with dignity throughout. The Linux subsystem maintainers acted like kindergarteners.

But of course, haters will read the same emails and confirmation bias will tell them they’re right and Rust is the problem.

Keep hating.

[lelanthran]

> I’m sure the Go community was called “hostile” by haters back in the day.

I was there, and no it wasn't. The Go community didn't jump into every programming discussion throwing around accusations of dinosaur, insecurity, etc.

[hunterpayne]

My friend, the OP in this very thread has in multiple posts, made outright slanderous comments about C programmers. The reputation of the Rust community is very much the making of the Rust promoters. If you are seeing pushback, that's just the consequences of such behavior.

I also notice that these language debates are very much generational. That has a few consequences. First is that older devs have thicker skin. Second, older devs are more wary of the big promises made by Rust. Whether you like it or not, the push for Rust very much comes across as naivete as much as anything to older, more experienced devs who have seen this type of thing before.

You can't write a device driver without manipulating memory directly. A OS Kernel has to manipulate memory directly by definition. Most academic research into memory safe languages is mixed with a high amount of null results (meaning it doesn't work). Yet the Rust folks push it as the 'one true way'. Meanwhile, most Rust OpenSource projects are abandoned currently.

Its not hate, its pointing out track record and avoiding repeating past mistakes due to painful experiences in our youth. Your determination to repeat past mistakes doesn't come across as enlightenment like you think it does.

[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.