[TheDong]

From the golang github org in non-toy code:

1. https://github.com/golang/tools/blob/f7d99c1a286d6ec8bd4516a...

2. https://github.com/golang/sync/blob/7fad2c9213e0821bd78435a9...

There are dozens and dozens throughout the stdlib and other popular go code.

The singleflight case is quite common, if you have:

    mu.Lock()
    if something() {
      mu.Unlock()
      moreWorkThatDoesntWantMutex()
      return
    }
    mu.Unlock()

most gophers use manual lock/unlocks to be able to unlock early in an 'if' before a 'return', and that comes up often enough that it really does happen.

I see manual lock/unlock all the time, and semi-regularly run into deadlocks caused by it. Maybe you don't use any third-party open source libraries, in which case, good for you congrats.

[pstuart]

Maybe it's stockholm syndrome, but the "manual" unlocks in bite sized funcs don't bother me -- it's easy to see that it's going to be unlocked by the time the function returns.

[stouset]

Unless there’s a bug and it panics?

At a minimum now you’ve also got to scan for nil dereferences. Maybe that simple code between the mutex is pulled out into a function in a later commit. Then the function body is changed in the next commit to do something less simple.

This is all depressingly reminiscent of listening to die-hard C enthusiasts insist that avoiding use-after-free bugs and out of bounds reads and other issues are easy as long as you write code perfectly all the time. It’s easy as long as you just always do the right thing.

It’s okay to admit your language of choice has weaknesses. You don’t have to stop using go just because you can acknowledge that data races can creep in if you’re not diligent enough.

[pstuart]

I'm confused. I was responding to a complaint about "manual unlocks" (vs. the "certainty" of a Lock(); defer Unlock().

The examples pointed to in the stdlib to complain about that usage pattern could have easily done just that -- but they were optimized to shrink the window of the locking time. My take is that the code paths were simple enough to verify that it was safe to do, and being in the stdlib had both. enough eyes to validate and a driver (being foundational code).

I recognize that Go is far from perfect but think some of the pearl clutching is manufactured (OMG! nil pointers! -- they technically can happen but in my many years of coding in Go it hasn't been a problem of note.)

And of course we should recognize that the locking issue being brought up was a simple one and the story gets worse when talking about complicated concurrency. Then the Go story of "just use the race detector!" is tempered by the fact that it is only best effort and no guarantees that it's found everything (like a bloom filter of certainty).

So year, Go has footguns and other inadequacies (FFI is a bummer). But it's good enough for a lot of things. Rust is on my list to learn, so my only complaint about it is the steep learning curve and I'm an old lazy dev.