The biggest negative for me the author overlooked is the lack of non-nullable types. The positive thing the author doesn't mention is that it's easy to write in, nor that threading is really easy.
I did mention the pervasiveness of nil and the lack of sum types as negatives.
> The positive thing the author doesn't mention is that it's easy to write in
I didn't mention this because I think the "ease of writing" is superficial; thinking through edge cases is something that frequently consumes a lot more time than literally typing the code out.
Also, given that the compiler doesn't really give any useful suggestions when your code is wrong (something that happens more often when you're less experienced in a language, like I was here), ease of writing takes a significant hit.
> nor that threading is really easy.
I didn't cover this because I haven't had the chance to work on much code using goroutines, and I've tried to ground the post in what I have actual experience with.
Isn't this even worse in Rust?
Compared to Go, Rust makes many kinds of edge cases mechanically discoverable. You cannot forget them.
As in Go, you can of course handle them poorly, and sometimes this is an ergonomic win. E.g. it's basically always trivial to panic (same as missing some critical cases in Go) or return the wrong value (literally all other cases in Go).
The primary difference isn't how you handle them, it's if you are aware that there are edge cases. Go is extremely lax here.
I think generics are a great addition to the language, and I'd love to see sum types (which would allow Option to circumvent nullable types), but I think that's much less likely.