4 ms·

Neither Go, Java or C++ would catch that concurrency bug.

• Const-me 1y ago
  C# would catch the bug at compile time, just like Rust. https://www.rocksolidknowledge.com/articles/locking-asyncawait https://www.rocksolidknowledge.com/articles/locking-asyncawa...
  • notfed 1y ago
    It's almost as if this post was written in direct response to TFA to brag about how far ahead C# has been for over a decade.
    • tialaramex 1y ago
      The C# is basically showing the Monitor pattern, which was also a thing in Java last century. The Rust Mutex is an Owning Mutex which is a different feature whose benefit is that you need to take the lock to get at the protected data, which averts situations where you forget in some code but not others and create sync problems - in C# those may go undetected or may trigger a runtime exception, no guarantees. But perhaps even more importantly, and why other languages which could do the Owning Mutex often do not, Rust's borrow checking means the compiler will spot mistakes where you gave back the lock but retained access to the data it was protecting. So you're protected both ways - you can't forget to take the lock, and you also can't give it back without also giving back the access. Monitors prevent only the second (and only partly), an Owning Mutex in most languages prevents the first, but Rust prevents both.
  • IshKebab 1y ago
    I don't know C# but it looks like they added a specific check just for locks, which is far less powerful than Rust's Send/Sync.
• lenkite 1y ago
  > Neither Go, Java or C++ would catch that concurrency bug. That is incorrect. Java enforces that a monitor lock (or Lock) must be released by the same thread that acquired it. Attempting to unlock from a different thread throws IllegalMonitorStateException.
  • rapsey 1y ago
    At runtime instead of compile time, which is the point of the thread.