It still, like every other language/tool we have that shares state between threads, has race conditions, for example.

As an example, let's say you have two functions A and B. A only works properly if B has never ran for some reason. Let's say they both accept a reference to a value C, and B changes C's value somehow. Because this is rust, we can't have data races, so we wrap it in an ArcMutex or what have you. That doesn't impact the ordering of A and B at all.

If we spawn threads that execute A and B at the same time, it's up to the scheduler if A functions properly.

And that is my core complaint - data races are well-understood and preventable now, whether statically via Rust's borrow checker (or pure immutability in functional languages) or dynamically with tools like Go's -race detector.

Logic races remain an application-level problem regardless of language design.

Please copy and paste from my post where that's being asserted

> Its touted purely as a _memory_ safe language

Which is different from what was said... how?

> To claim otherwise is absurd and very telling of the writer's biases

To pretend that those claims were made is what's actually telling of biases.

Because memory safety isn't just about data races. In fact data races are far from Rust's most innovative or important feature. They are a side-effect, the designers had a nice system and saw it can also prevent data-races, so they said "sure, why not".

Maybe I spend too much time on tech internet...

Native UI with Crux backend. Best of both worlds.