6 ms·
Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial
by bluejekyll 6y ago
Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time.
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.
- Chilinot 6y agoYou dont necessarily need to use locks in the db. You can use transactions as well, unless you want to do major changes to the DB where transactions would be in constant conflict state.
- bluejekyll 6y agoYou’re right, though that wasn’t really the point of my reply. More that concurrency in the DB is a DB design choice and not the responsibility of the language accessing the DB. This is especially true when accessing the DB from multiple nodes, which most deployed software does.
- branko_d 6y agoLocks and transactions are intertwined. Write locks are typically released only when the transaction ends, and read locks too at some transaction isolation levels.
- pjmlp 6y agoIndeed, but the fearless concurrency sales pitch tends to overlook that.
- ben0x539 6y agoThe fearless concurrency sales pitch doesn't overpromise. You're trying to stretch it, but it's pretty clear on what kind of concurrency issues it covers (eg. data races).
- hderms 6y agoYeah it would be a grave misinterpretation of "fearless concurrency" to think Rust somehow validates that access to some shared resource with it's own semantics is also safe. I'm not educated on the subject but that problem seems pretty intractable for a language to solve in a general sense.
- pjmlp 6y agoIndeed, yet that is not how many Rust advocacy blog posts sell it.
- shakow 6y agoSuch as?
- pjmlp 6y agoAny blog post that gives examples accessing shared variables and never goes beyond anything else, leaving to the reader that it works the same way regardless of what resources are being accessed. https://blog.knoldus.com/how-we-can-do-fearless-concurrency-in-rust/ 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. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
- shakow 6y agoYou really had to dig a post that has less text than code? > 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.
- trunnell 6y agoIt’s hard to see how you could be arguing in good faith given that your point of “fearless concurrency” being an overstated “sales pitch” has now been answered with multiple substantive answers. 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.
- pjmlp 6y agoRust is honest, https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html 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.
- masklinn 6y ago> Rust won’t prevent all manner of bugs Nit: rust will prevent all manner of bugs. Rust won't prevent every manner of bugs.