None of them solve the problems associated with the general category of race conditions. You can trivially create live/dead locks with channel/message-passing, and rust only prevents data races, though ownership is definitely a step in the right direction.
(Well, go is not even memory safe under data races!)
Also, Java is one of the languages where you can just add `synchronized` as part of the method signature, and while this definitely doesn't solve the problem, I don't think "divorced from the data" is accurate.
Re: 'synchronized' and data. It is a good distinction to make because sync does indeed lock control, not data. With ACID transactions or STM, an atomic section will run as-if-sequentially, full stop, since the data is locked. With Java sync, you get 'no other thread is in these lines of code' and you have to hope that's enough for the system to run as-if-sequentially.
I think it's an interesting distinction, but it's sort of OOP's main thing to encapsulate the local (possibly mutable) state, so that using an object externally will leave the inner state correct.
I think the primary issue here is that synchronized should be the default case, with optionally lifting that very strict restriction for multi-threaded access.
Nonetheless, objects with methods that would do STM on their inner state would be a pretty cool design.
(Well, go is not even memory safe under data races!)
Also, Java is one of the languages where you can just add `synchronized` as part of the method signature, and while this definitely doesn't solve the problem, I don't think "divorced from the data" is accurate.