> At least in Java you can't write bad logic that also suffers from memory issues.

Oh you bet you can. There are a number of ways to screw that up.

- memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs

- using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly

- using native calls incorrectly can be just as nasty

I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects.

Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare).

(Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)

> Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects.

Your project may not use it directly, but there’s a pretty good chance one of your libraries does.

And when I code in C, there's typically at least one library with inline assembly even though my C doesn't use any inline assembly.

There is indeed a difference here between the vast majority taking part in risky behavior and library authors using focused performance improvements. There are a lot more eyes on the library code due to downstream effects than in everyday top-level code.