Hacker News Reader

Comment by smokey_circles | Hacker News Reader

I've never had an issue with data race conditions in go. Can I ask what you did to lose faith?

The answer, for me, is always channels. What you put around the channels is the challenging part.

Channels are built to pass information between goroutines. If you are doing this via any other signaling, just don't. You can loop over channels for long running sequential reads, you can test them to see if they're ready to read or ready to write.

Honorable mention to context as well, extremely useful structure.

View on HN

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?

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.

> 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

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.

Reply on news.ycombinator.com