> I also ascribe that issue to the subject of nil in Go, which is a whole other topic, this article is about errors. I’ll bite. Idiomatic Go code, as in the ar

> I also ascribe that issue to the subject of nil in Go, which is a whole other topic, this article is about errors. I’ll bite. Idiomatic Go code, as in the article, does: response, err := somethingorother() In the error case, response needs to have a value, and nil serves this purpose. If response were a non-nillable type, this would not work. Result-style types solve this problem.