>Here we start to see some sources of real bugs. Writing to and reading from a nil channel blocks forever.
Of course they block forever. If you read from a channel that nothing is writing to it, you block forever. If you write to a channel that nothing reads from it, you block forever. There's nothing special related to the channel being nil.
Trying to assigning to a nil map is also perfectly understandable: a nil map is read only. This is the same as nil slices. "But `a = append(a, 1)` works when a is nil", you might be asking. Yes. That's because `append(a, 1)` is not (always) writing to a.
>Here we start to see some sources of real bugs. Writing to and reading from a nil channel blocks forever.
Of course they block forever. If you read from a channel that nothing is writing to it, you block forever. If you write to a channel that nothing reads from it, you block forever. There's nothing special related to the channel being nil.
Trying to assigning to a nil map is also perfectly understandable: a nil map is read only. This is the same as nil slices. "But `a = append(a, 1)` works when a is nil", you might be asking. Yes. That's because `append(a, 1)` is not (always) writing to a.
Then it talks about typed nils. Yes typed nils can be a footgun, but I've been writing go code professionally for almost 5 years now and I've been bitten by that exactly once (I've written about it here: https://wang.yuxuan.org/blog/item/2020/09/typed-nil-in-go). In most cases, typed nils are more useful than being a footgun. See https://pkg.go.dev/github.com/reddit/baseplate.go/log#Wrappe... and https://pkg.go.dev/github.com/apache/thrift/lib/go/thrift#TC... for a few examples of typed nils are being useful and providing useful zero values.