A couple of remarks. FWIW my job is as a Go programmer.
The unused variable thing (particularly with local variables) has caught many bugs quickly for me. If there's a package that I find myself always adding and removing, it's easy to write a function that freezes it. For instance, for the debugging print example:
(I tend to use log for debugging prints rather than fmt, because it's guaranteed thread-safe, and it's easier to separate debugging prints from necessary prints at a later stage).
On the few occasions that I've really felt I lacked a ternary operator, I've just coded one up for the occasion:
func either(cond bool, a, b string) string {
if cond {
return a
}
return b
}
No big deal. I do find myself writing little functions as building blocks quite a lot, but I think this works well. Functions are a great building block, and Go is great for assembling blocks.
Question: how do you feel about the lack of exceptions? To me, that's the biggest drawback to Go as it feels like sacrificing a major improvement in reliability and boilerplate reduction (obviously with Python-style syntax, not Java).
I don't agree that exceptions necessarily improve reliability or reduce boilerplate.
But in any case, I've found I usually do better error handling in Go.
Seeing the "multiple-value ... in single-value context" compiler error message immediately tells me that the function I'm calling either doesn't do what I think, or (more usual) that I'm not handling an error return value.
When I fix the compile error I have to consciously decide how the error will be handled. Will I ignore it by assigning it to "_"? Will I pass it to a generic error handling function? Will I do special case handling?
On the other hand, in Python it's really easy to ignore the exceptions that can be thrown by a function. The interpreter doesn't help at all. If I leave out a try/except block then I don't find out about it until runtime, and only then if I get lucky (unlucky?).
How does it sacrifice reliability? Are try/catch blocks not also their own flavor of boilerplate? All error codes do is put the error handling you ought to be doing in the first place near the area an error could occur.
See also Raymond Chen's posts about good vs bad exception handling (H/t Russ Cox on G+):
The `either` function is really crippled compared to a proper ternary operator; it works only for strings, and both `a` and `b` are evaluated at the call site, so side effects in those expressions are out.
The unused variable thing (particularly with local variables) has caught many bugs quickly for me. If there's a package that I find myself always adding and removing, it's easy to write a function that freezes it. For instance, for the debugging print example:
(I tend to use log for debugging prints rather than fmt, because it's guaranteed thread-safe, and it's easier to separate debugging prints from necessary prints at a later stage).On the few occasions that I've really felt I lacked a ternary operator, I've just coded one up for the occasion:
No big deal. I do find myself writing little functions as building blocks quite a lot, but I think this works well. Functions are a great building block, and Go is great for assembling blocks.