> And exception handling If you read & write Go regularly, the rather verbose error handling simply fades into the background. That said, errors in Go don't r

> And exception handling If you read & write Go regularly, the rather verbose error handling simply fades into the background. That said, errors in Go don't really translate to Exceptions as generally thought of; panic, however; may be does. Making changes to error handling wasn't for the lack of trying, though: https://news.ycombinator.com/item?id=44171677 https://news.ycombinator.com/item?id=44171677 > issue with nil pointers This is why most APIs strive for a non-nil zero value, where possible, as methods (on structs) can still dictate if it will act on a pointer. Though, I get what you're saying with Go missing Optional / Maybe / ? operator, as the only other way to warn about nil types is through documentation; ex: https://github.com/tailscale/tailscale/blob/afaa23c3b4/syncs/syncs.go#L148 https://github.com/tailscale/tailscale/blob/afaa23c3b4/syncs... (a recent example I stumbled upon). Static code analysers like nilaway (https://news.ycombinator.com/item?id=38300425 https://news.ycombinator.com/item?id=38300425) help, but these aren't without false positives (annoying) & false negatives (fatal).