For multi-process data-structures using inter-process shared memory, you can still write Rust APIs that protect you from data-races as long as all processes inv

For multi-process data-structures using inter-process shared memory, you can still write Rust APIs that protect you from data-races as long as all processes involved use those APIs. If they don't, then protection is up to the operating system (you can lock and unlock shared memory, but whether processes can violate the locks is an OS thing). For distributed computing, you typically use message passing of some form via network sockets, that's "safe" by design. You can also use RDMA, and there usually your process needs to opt into that, create an RDMA readable/writable region, and you are back to the mercy of your network stack up to which kind of protection you can enforce there. From Rust point-of-view, if you make the wrong assumptions about shared memory or RDMA regions, your program has a bug. The fix is simple, use appropriate atomic (or atomic volatile) to read/write from those regions. Even if another process is writing while you are reading, as long as the operations are the right ones (e.g. <128-bit atomic reads/writes), you can avoid memory unsafety and data races. This won't protect you from deadlocks or race conditions, etc. but that's not something that any programming language does. Rust has deadlock protection within a process, but that's not required for safety, so it is an extra feature on top.