I just vibecofed tsasm. tsrs is obsolete now and anyone who still uses it is hopelessly behind the times. The tsrs team should delete the repository immediately and join my project.
It still, like every other language/tool we have that shares state between threads, has race conditions, for example.
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...
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.
Native UI with Crux backend. Best of both worlds.