[metadat]

I read the Uber article linked in parent.

"Data Race Patterns in Go", posted 21 days ago: https://news.ycombinator.com/item?id=31698503

Even though I'm extremely careful, I'm sure I've done one or more of the anti-patterns they outline where the outcome is completely incorrect program behavior compared to my intentions as the architect of the program.

A good language wouldn't encourage or even compile with such nonsense.

---

Isn't it funny how Go offers channels but the stdlib never uses them at all?

[q3k]

> Isn't it funny how Go offers channels but the stdlib never uses them at all?

    go/src $ grep -r 'chan ' | grep -v test | wc -l
    402

    go/src $ grep -r 'Mutex' | grep -v test | wc -l
    362

[kubanczyk]

Yes, that Uber article hit close to home.

About 80% of these problems can be covered with new linter rules. Go as a language already strongly depends on linter rules. I mean, there are a few must-haves already, and adding a few more won't make much difference. This isn't optimal, but it's not a deadly flaw of Go ecosystem.

Remaining 20% need solid test coverage (using -race). You are right, these absolutely need attention from Go language creators/architects. In their terms, these kinds of promises which shouldn't have been made for v1.0.

[xh-dude]

Hmm, the std lib uses channels for a variety of scheduling hook sorts of things - contexts, timers, os signals for example. That’s maybe just a little narrower than how Go users can use them - they aren’t really for transport, but for synchronization (just as useful for no or small payloads as large ones).

It doesn’t similarly expose mutexes that package clients have to fiddle with.