4 ms·
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 t
by rogpeppe1 14y ago
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:
func printf(f string, args ...interface{}) {
log.Printf(f, args...)
}
(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.
- acdha 14y agoQuestion: 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).
- wonderzombie 14y agoHow 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+): http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/11816... http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
- jlarocco 14y agoI 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?).
- gnuvince 14y agoThe `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.
- rat87 14y agocough generics cough I suppose you could cast it, also use a Function literals for delayed evaluation.
- ralph 14y agoA ternary op, Python's is nice, would be welcome. ;-) map[bool]int{false: 3, true: 14}[foo != 0]
- jmpeax 14y ago> The unused variable thing (particularly with local variables) has caught many bugs quickly for me. I agree, unused variables in any language are great for catching bugs. This isn't an argument for unused as errors instead of warnings.