typesanitizer

If you look at the GopherCon talk I gave (linked at the beginning of the post), it is about reading the spec. So yes, I did read the spec, and I realize that this is not syntactically valid (it would be a very basic compiler bug if this were valid syntax and it was diagnosed as a syntax error).

However, the spec only states what _is_ but not _why_ it is that way. Sure, I could look at the git blame of the spec for every odd thing I run into, but there is only so much time in the day...

> 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.

This is a fair point. To be clear, I wasn't suggesting Canonicalize as _the_ name, but as one potential candidate. As you've shown, it has some shortcomings. Perhaps Normalize is a better alternative (and also another candidate that I suggest), since "Normalization" is a commonly used term for converting to a standard/normal form.

Thanks! I'm a fan of your work and posts on Ninja, so I'm glad to hear this. :)

> I don't think it focused enough on the positives (of which I think there is some - for example, it has very nice and highly performant lightweight threads with full blocking semantics via goroutines).

I've tried to focus on things that I ran into. I haven't had the chance to write a lot of concurrent code in Go, that's why I didn't comment on this aspect. Most of the code I've been working on has been serial, with concurrency and parallelism managed at a different layer than the one I was working on.

That said, the same point applies for a bunch of negative points that you may seen in other articles criticizing Go. I didn't mention them because I didn't run into them in practice.