When I see code like this I will assume that it's going to check every condition:
if !complete {
// do something
}
if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 {
// do something
}
if r.Created {
// do something
}
If the first condition matching causes the second, third, nth condition to not be checked then why not make it clear in the code by adding an `else`?The recommended way means that I can't trust my assumption and that I'll have to read the entire function and examine the `//do something`s instead
For that matter, if you hate C programming --- not in the sense of "C is dangerous and error prone" and more in the sense of "I hate the way I feel when I write C code", you also aren't going to like Golang.
The former issue grinds on me a bit, though I'm coming to appreciate what it does for the reliability of my code versus languages with exceptions. On the other hand, I love writing C code, and that probably makes up for it.
I would not say I've grown to like the error handling, but when I trudge through it now, I do so realizing that there's probably an actual benefit to my program of the annoyance.
The Go standard library is also really, really well designed.