There are many things which cause both frequent and rare strange crashes in multi-threaded code.
In C, all these things will compile OK. In safe Rust, practically none of them will compile.
It is much easier to fix compile issues in Rust to do with dangerous memory usage or thread sharing than it is to debug a compiled program.
If you need to do it across processes, then you need a file system that supports exclusive file opens.
The db question is a red-herring, because to properly solve for concurrency in the db, you need to use locks in the db (table and row locks), not the code accessing the db.
https://blog.knoldus.com/how-we-can-do-fearless-concurrency-...
Now rewrite the same blog post using SQL queries to update the same counter variable on a table row.
The Rustonomicon is quite clear that it wouldn't work,
> However Rust does not prevent general race conditions.
> leaving to the reader that it works the same way regardless of what resources are being accessed.
If that's how readers envision that non-language-managed resources work, they should go back to CS102 right now.
And concerning the nomicon, it explicitly states that Rust can't handle all races condition, I don't get your point.
Please stop moving the goal posts from “program concurrency” to “distributed or multi-process transactions.” It subtracts from the conversation.
Rust is honest about what it does and doesn’t do.
I am not moving goal posts, rather talking about issues that many apparently lack the knowledge to understand how many variants of data races exist in an application.
Quite understanable given the majority of developers that keep writing single threaded applications.
Nit: rust will prevent all manner of bugs. Rust won't prevent every manner of bugs.
But you're right to point out that Rust won't magically solve all your possible sources of crash and data corruption, it just does make it a lot easier to enforce arbitrary constraints. For instance if you decide that in order to avoid these issues you want all your DB stuff to only run in a single thread you could design your API in a way that would prevent DB handles from being shared between threads, all that enforced by the language. You couldn't accidentally leak a DB handle to a different thread.
All the rust db interfaces I've seen so far forbid unlocked sharing of connections, statically (the connections are !Sync, in Rust speak).