[pjmlp]

I have tried plenty of times, and seen not so happy train travelers with the same ticket for the same place on the same train, hence why bring it up all the time.

It is obvious it is a subject that is irrelevant in the Rust community.

Who needs consistency in distributed systems when multiple threads from the same process are accessing the same external data without coordination.

[tialaramex]

> Who needs consistency

Programmers do. Programmers are human and so can't reason about the behaviour of non-trivial programs without sequential consistency.

If I was trying to debug software which sometimes mistakenly issues people duplicate tickets, I think I'd want to be able to reason about how the software works, and that's not going to be possible if it doesn't even exhibit sequential consistency.

[ncmncm]

Your argument amounts to "Rust prevents X, so X is important. Rust cannot prevent Y, therefore Y is less important."

[tialaramex]

Er, no? Sequential consistency isn't some Rust invention, Leslie Lamport (yes the LaTeX one) invented it for his 1979 paper "How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs"

I rather like Lamport's last observation about what happens if you don't have sequential consistency and instead your programs just put up with whatever was cheap/ efficient to implement (as will happen by default on a modern multi-core CPU): "verifying their correctness becomes a monumental task"

It was later proved that it's not merely "monumental" this is actually an undecidable problem in general which explains why humans aren't good at it.

So, this is important in principle to get right, and (safe) Rust does so. You are of course welcome to decide you don't care, why aim to write correct programs anyway? And for now at least it seems in our industry many people agree.