3 ms·

Well, maybe that's open to the interpretation of "prevents mistakes" in the text I guess :) I'd argue that "It prevents mistakes with ref counting, locking, bo

Well, maybe that's open to the interpretation of "prevents mistakes" in the text I guess :) I'd argue that "It prevents mistakes with ref counting, locking, bounds checking..." implies "all" mistakes, but hey, maybe not...

nextaccountic 3y ago
Rust-style locks definitely raise the bar, and I wish more languages adopted this - like this https://news.ycombinator.com/item?id=35464152 https://news.ycombinator.com/item?id=35464152 or https://github.com/dragazo/rustex https://github.com/dragazo/rustex
- masklinn 3y ago
  Yeah just the mutex style (the mutex being a container) even without borrow checker is already progress because it shows the dependency between the lock and the data in the code. The main missing piece in rust locks is inter-lock dependencies when they are not nested.
- thesuperbigfrog 3y ago
  >> Rust-style locks definitely raise the bar, and I wish more languages adopted this This locking pattern is quite old and frequently available in safe languages. Ada calls it "protected objects" and has had it since Ada 95: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html#protected-objects https://learn.adacore.com/courses/intro-to-ada/chapters/task... Java calls it "synchronized" and has had it since Java 5 or 6: https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...
  - _flux 3y ago
    If I'm not misunderstanding it, those always associate exactly one lock to a exactly one object, which is not what Rust locking is. The Rust (also C++) mechanism is that when you lock a mutex you get a lock guard object and when the scope ends the guard is dropped and therefore the mutex is released; you don't need to put the code accessing the locked data inside a particular locking object. For example, how would one implement https://doc.rust-lang.org/std/sync/struct.RwLock.html https://doc.rust-lang.org/std/sync/struct.RwLock.html with that?
    - _flux 3y ago
      I realize that that is actually factually incorrect: you do associate the contents to the locks in Rust, e.g. RwLock<Contents>, though the structure is a bit different as an object doesn't inherently to have a lock. However, you do get to choose what kind of locking scheme you use and, crucially, it is impossible to access said data without holding a lock. Indeed it is not possible to have concurrent access on data without having some locking implemented and used.
  - insanitybit 3y ago
    A difference being that you're safe even without a Mutex at zero cost.
- loeg 3y ago
  folly::Synchronized provides a similar pattern in C++. I guess it's not widely used outside of Facebook, but it is commonly used inside Facebook FWIW.
brookst 3y ago
Fairly ambiguous. “Prevents some mistakes” would be more clear, but I also don’t read “prevents” as “eliminates the possibility of”.

nextaccountic 3y ago

Rust-style locks definitely raise the bar, and I wish more languages adopted this - like this https://news.ycombinator.com/item?id=35464152 https://news.ycombinator.com/item?id=35464152 or https://github.com/dragazo/rustex https://github.com/dragazo/rustex

masklinn 3y ago
Yeah just the mutex style (the mutex being a container) even without borrow checker is already progress because it shows the dependency between the lock and the data in the code. The main missing piece in rust locks is inter-lock dependencies when they are not nested.
thesuperbigfrog 3y ago
>> Rust-style locks definitely raise the bar, and I wish more languages adopted this This locking pattern is quite old and frequently available in safe languages. Ada calls it "protected objects" and has had it since Ada 95: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html#protected-objects https://learn.adacore.com/courses/intro-to-ada/chapters/task... Java calls it "synchronized" and has had it since Java 5 or 6: https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...
- _flux 3y ago
  If I'm not misunderstanding it, those always associate exactly one lock to a exactly one object, which is not what Rust locking is. The Rust (also C++) mechanism is that when you lock a mutex you get a lock guard object and when the scope ends the guard is dropped and therefore the mutex is released; you don't need to put the code accessing the locked data inside a particular locking object. For example, how would one implement https://doc.rust-lang.org/std/sync/struct.RwLock.html https://doc.rust-lang.org/std/sync/struct.RwLock.html with that?
  - _flux 3y ago
    I realize that that is actually factually incorrect: you do associate the contents to the locks in Rust, e.g. RwLock<Contents>, though the structure is a bit different as an object doesn't inherently to have a lock. However, you do get to choose what kind of locking scheme you use and, crucially, it is impossible to access said data without holding a lock. Indeed it is not possible to have concurrent access on data without having some locking implemented and used.
- insanitybit 3y ago
  A difference being that you're safe even without a Mutex at zero cost.
loeg 3y ago
folly::Synchronized provides a similar pattern in C++. I guess it's not widely used outside of Facebook, but it is commonly used inside Facebook FWIW.

brookst 3y ago

Fairly ambiguous. “Prevents some mistakes” would be more clear, but I also don’t read “prevents” as “eliminates the possibility of”.