4 ms·
Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. It turns out that the verbosit
by maxaf 9y ago
Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. It turns out that the verbosity of, for example, Go's error handling is actually simpler to understand and easier to read than any monadic contraption I've seen in the wild. It's also safer and lighter than Java's use of exceptions (checked or otherwise) because of the non-exceptional nature of equality comparisons and multi-valued returns.
Lastly, the idea that generics somehow remove the pain of null pointers is simply false. I've done 8 years of Scala before defecting to Go, and still have nightmares about an empty Option[T] that has caused some n-level-deep monadic computation to return nothing. In this case, Go would at least blow up with a helpful stack trace, while the Scala program would continue to run and return erroneous results.
- yen223 9y agoThe notion that verbose == easy-to-read is a myth that needs to die
- weberc2 9y agoNot as much as the "code golf is easy to read" myth that is popular among language communities that advertise their minimal line counts.
- kasey_junk 9y agoI think the argument that ‘Scala is over complex’ is not a compelling argument against the premise that ‘go is too simple’. Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. Don’t get me started on the golang generics & concurrency problems. I continue to use golang in spite of their language decisions around these items, not because of them.
- kasey_junk 9y agoAs an aside, I answered all of these questions in a way that the blog post describes as positive yet am very critical of go in reality.
- sagichmal 9y ago> Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. This has not been my experience. Idiomatic Go -- that is, not trying to do obtuse, clever, or dumb things to avoid error handling -- results in very clean and error-free code by default. I see unexpected runtime errors maybe a few times a year. I haven't seen unexpected panics in years.
- kasey_junk 9y agoSerious question, when you see non obtuse, clever or dumb things for error handling how do you attribute language?
- sagichmal 9y agoAttribute language? I'm not sure what you mean. In Go there is typically a very restricted set of ways to idiomatically accomplish a given task, often only one. Error management is a prime example. result, err := function() What do you do with err? If it is recoverable, you should try to recover from it. if err == ErrTryAgain { continue } Generally errors aren't recoverable, and should be reported back up the stack with some kind of contextual annotation. if err != nil { return fmt.Errorf("function failed: %v", err) } If you want to provide more context to your caller, to enable a richer set of responses to this error, you can use more structure. if err != nil { return FunctionError{Original: err, ...} } That's really about it. Anything that tries to subvert the very simple/plain `if` checking, or tries to perform some kind of monadic error chaining, or builds an ersatz exception system with panic/recover, is what I mean when I talk about "obtuse, clever, or dumb things". The language and its idioms form these expectations.
- tptacek 9y agoThis is in fact not idiomatic Go style. The Go error idiom is that errors are values, and that if you want cleaner error abstractions, you just program them yourself. People make trees of errors, or aggregate errors and check them once, or have error stacks. "continue" doesn't recover from an error, obviously. It is not hard to find screwups in error recovery code in Go. Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the major Go error handling warts. Since you (like everyone else) didn't create an error variable or type to capture any of the meaning of the error, what you've created is a by-design unrecoverable error, one where your only hope of responding in any way other than aborting the entire operation is to parse the string error message, which is something more than one Go program has had to do. I don't think this is a very strong rebuttal to "Go error handling kind of sucks".
- sjellis 9y ago"Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written." Yes, it honestly sounds like a taste issue. Go has it's own patterns, so if you instinctively expect your code to be like another language, it will probably feel wrong. I suspect that it is at the root of a lot of the comments about generics: people aren't comfortable with the style of Go, but aren't sure why, so they latch on to "generics".
- flavio81 9y ago>Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. Code also needs to be written quickly and cleanly so it can be augmented later. I don't think Go contributes in this regard.