3 ms·

I'm not following what you're saying. I'm saying "mu.Unlock()" except when deferred, is essentially always a bug. At the very least it's a bug waiting to happe

I'm not following what you're saying. I'm saying "mu.Unlock()" except when deferred, is essentially always a bug. At the very least it's a bug waiting to happen. You need to prove that everything between Lock and Unlock is exception-safe. And that's rarely possible. As I've said elsewhere you cannot rely on panic triggering program exit, since e.g. HTTP handlers swallow panics. The fact that you seem to be saying you never see an Unlock deferred proves my point that saying "Go doesn't have exceptions" hurts Go programming. And Go code is in fact full of bugs because there's all this exception-unsafe code. C++ is naturally exception safe, because RAII. Where it's not exception safe it's because RAII was not used. Even something as simple as: mu.Lock() stats[metricName]++ mu.Unlock() will throw if there's a path where stats[] map was not inited, and if called in an HTTP handler will leave the lock in place, leading to probably a deadlock of the server. Not great.

steveklabnik 6y ago
The Rust code would be, roughly (I tried to keep names similar even though Rust would use a slightly different naming scheme) let someoneElsesObject = mu.lock(); println!("{}", someoneElsesObject); return; when someoneElsesObject goes out of scope, the mutex is unlocked. This happens no matter how it goes out of scope. You cannot forget to do it, because the only way to get access to someoneElsesObject in the first place is locking the mutex, because mutexes wrap the data that they are protecting. https://crates.io/crates/defer https://crates.io/crates/defer exists, but it would be weird to try and use it here, because it can't really be combined directly with this. I guess in theory you could put drop(someoneElsesObject) in the defer block, but like... that already happens for free.
- knorker 6y ago
  Ah, that looks neat. Among my huge backlog project list, learning Rust is on there. Yeah looks more RAII, and looks like it would not have the problem Go has. Thanks.

steveklabnik 6y ago

The Rust code would be, roughly (I tried to keep names similar even though Rust would use a slightly different naming scheme) let someoneElsesObject = mu.lock(); println!("{}", someoneElsesObject); return; when someoneElsesObject goes out of scope, the mutex is unlocked. This happens no matter how it goes out of scope. You cannot forget to do it, because the only way to get access to someoneElsesObject in the first place is locking the mutex, because mutexes wrap the data that they are protecting. https://crates.io/crates/defer https://crates.io/crates/defer exists, but it would be weird to try and use it here, because it can't really be combined directly with this. I guess in theory you could put drop(someoneElsesObject) in the defer block, but like... that already happens for free.

knorker 6y ago
Ah, that looks neat. Among my huge backlog project list, learning Rust is on there. Yeah looks more RAII, and looks like it would not have the problem Go has. Thanks.