[typesanitizer]

> The biggest negative for me the author overlooked is the lack of non-nullable types.

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.

[Andys]

> thinking through edge cases is something that frequently consumes a lot more time than literally typing the code out.

Isn't this even worse in Rust?

[kbknapp]

In Rust the edge cases are often more apparent because you're often forced to at least acknowledge them. So while you do have to put thought into handling them, you don't have to spend much thought finding or worrying about missing them.

[Groxx]

As a different way to express this:

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.