Java doesn't have this problem.
> As soon as you have something larger than the hardware atomic size (or unaligned in memory) you risk torn reads/writes. So a pointer + a size for example on some architectures (some hardware like x86 has a double word atomic support, but on embedded you usually only get up to word size atomics).
Well, the reading of a stale pointer alone could lead to UAF even without tearing.
> All this means that you can't (in a systems level language) feasibly make everything atomic and ensure no UB.
I didn't say no UB. I get that Rust decided to do something (no UB in the safe subset) and this is a consequence of that, but my point is that it's not obvious it's the best goal in the first place. Certain patterns are known to be the cause of a majority of vulnerabilities in C and C++, so it makes sense to sacrifice something to address them, but once you get to bugs that are no more common as vulnerabilities as many other bugs that Rust doesn't stop, saying we must stop these bugs and not others, even at the cost of requiring more programs to use the unsafe subset is one possible tradeoff but not a universally superior one.