sync

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.

A non-blocking send would work just as well for that issue, is a standard part of the language, and would support user-supplied channels, but it would still be at risk of panicking when sending to a closed channel. I think there ought to be a safe way to send to a closed channel, but the language authors disagree, so that's not really on the library authors (though they could still recover from the panic). However, not closing the channel you specifically chose to control all sending to is just lazy/rude. Even though the caller should receive from the channel once and then forget about it, closing the channel after sending would prevent incorrect subsequent receives from hanging forever. All this having been said, contributing to these libraries seems better than complaining about them, but I don't know how the golang.org/x stuff is maint

1) using channels + goroutine to implement a map doesn't seem like the most sensible thing to do; even golang's new sync.Map type is implemented with mutexs (eg https://github.com/golang/sync/blob/master/syncmap/map.go#L2...). Idiomatic doesn't mean ALWAYS do this no matter what; it is the natural thing to do if it feels like the right approach. 2) Don't use "considered harmful" so much; it is considered harmful.

This was when I kind of lost interest, as it became clear generics would never happen. In the early days I was enthusiastic enough that I tried to provide support for the os.user implementation on Windows. Nowadays I just advocate Go for C use cases, where the use of a tracing GC is not an hindrance as a way for us to enjoy safer computing. Oh, and the code of the new syncmap.Map is full of unsafe.Pointer as workaround for lack of generics, while achieving good performance. https://github.com/golang/sync/blob/master/syncmap/map.go