You've misunderstood the example. The `scores` channel aggregates scores from all players, you can't close it just because one player leaves.
I'd really, really recommend that you try writing the code, like the post encourages. It's so much harder than it looks, which neatly sums up my overall experience with Go channels.
It’s not entirely clear whether the author is describing a single or multiplayer game.
Among the errors in the multiplayer case is the lack of score attribution which isn’t a bug with channels as much as it’s using an int channel when you needed a struct channel.
In both examples, the HandlePlayer for loop only exits if .NextScore returns an error.
In both cases, you’d need to keep track of connected players to stop the game loop and teardown the Game instance. Closing the channel during that teardown is not a hurdle.
What am I missing?
I think nothing
I was thinking the same, the only problem is the author not keeping track of players
On HandlePlayer return err you would decrement a g.players counter, or something, and in the Game.run just do if !g.hasPlayers() break close(g.scores)
The solution requires nothing special, just basic logic that should probably be there anyway
If anything this post shows that mutexes are worse, by making bad code work