I've been seriously turned off from go (after dedicating years of my life to it :(). It is fundamentally flawed IMHO, a house of cards built on quicksand.
I wonder what we'll think of GO in 5, 10, 25 years. Within 50 years I kinda doubt many humans will give a crap about it at all.
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.
"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?
It doesn’t similarly expose mutexes that package clients have to fiddle with.
go/src $ grep -r 'chan ' | grep -v test | wc -l
402
go/src $ grep -r 'Mutex' | grep -v test | wc -l
362About 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.