3 ms·
So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error h
by vertex-four 10y ago
So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error handling problem, which has resulted in some of my code being more about the failure case than the success case.
Of course, others will disagree - fine. But to argue that e.g. Java is definitely the screwdriver is a subjective judgement.
- eropple 10y agoTo add to this: Go's inexpressivity (hi, generics!) makes common patterns that I see in Kotlin, Java, and Scala (as well as Rust, off-JVM) makes error handling a complete bear, to the point where my eyebrows are really raised at vertex-four being downvoted for this. The use of please-check-this error conditions instead of something like a Try<T, E> (Result<V, E> in Rust) and an inability to just map over these as 0- or 1-element collections is such a huge pain, and it certainly does matter when you're piling up multiple error-handling cases. Even more when you'd otherwise use Scala's `recover` to get back on a happy path. Go's inexpressivity directly impinges on one's ability to get things done. (Food for thought: forgetting to handle the error case from Rust's Result<V, E> is a compiler error. Is "if err != nil" really that good an idea in such a universe?)
- chrismorgan 10y agoNot using a Result is a warning, not an error: https://is.gd/U43rdG https://is.gd/U43rdG
- eropple 10y agoSorry, yes (I compile with warnings as errors), good catch.
- mratzloff 10y agoYou must explicitly ignore errors in Go. result, _ := someFunc()
- kasey_junk 10y agoNot if they are the only return value. You should use an analysis tool to avoid this but nothing about the language requires it.
- mratzloff 10y agoAh, you are right.