Hacker News Reader

Comment by mitchellh | Hacker News Reader

> unless you check the error return code of practically every statements

Yes, you MUST. That is just how Go does things. If you don't do this, then of course things are going to blow up at runtime. Your "unless" is the same as saying in a language like Java: unless you rescue the exceptions, the program crashes! Yes, clearly.

Personally, I love Go's error handling. I made a joking tweet one time that over 10% of all lines of code in Packer are "if err != nil". That is still probably true, but I don't think its a bad thing.

We also make Serf, which is powering some pretty large infrastructures out there, and we've never ONCE had a crash in production. Not once. We've had errors, but they were logged and handled. I attribute this to the fact that we were forced to handle every error.

Some people like exceptions, but I've always liked Go's way of things in this department.

View on HN

If 10% of your lines are repetitions of the same thing that's absolutely a problem with the language. You should find a more concise way to express the same thing (e.g. error monad).

To expand, Go's type system is relatively rudimentary. The lack of option types[0] leads to this fairly common, verbose Go pattern:

    func DoFoo(Foo foo) Cat {
        bar, err := GetBar(foo)
        if (err != nil) { return nil }

        baz, err := GetBaz(bar)
        if (err != nil) { return nil }

        cat, err := GetCat(baz)
        if (err != nil) { return nil }

        return cat
    }

Option types add metadata to a type, essentially combining `bar` and `err` into a single variable. Let `Maybe x` mean a function will return `Something x` or `Nothing`. For example (in hypothetical Go):

    func DoFoo(Foo foo) Maybe Cat {
        bar := GetBar(foo)
        if (bar.(type) == Nothing) { return Nothing }

        baz := GetBaz(bar)
        if (baz.(type) == Nothing) { return Nothing }

        cat := GetCat(baz)
        if (cat.(type) == Nothing) { return Nothing }

        return cat
    }

Since this is such a common pattern, Haskell has a bind operator (`>>=`) to take advantage of option types by passing the output as the input of the next function if it's a `Something`, or return `Nothing`.

    func DoFoo(Foo foo) Maybe Cat {
        return GetBar foo >>= GetBaz >>= GetCat
    }

If you care about why something failed, use an `Either` instead of a `Maybe`. In a language that supports algebraic data types, you could create your own sum type instead.

[0] https://en.wikipedia.org/wiki/Option_type

Now you've got way less code, and way more cognitive load per line.

There's a reason why hideous Java is so successful while beautiful Haskell is a punchline to jokes.

Many languages besides Haskell have option types (Rust, Scala, OCaml, Java 8):

http://www.oracle.com/technetwork/articles/java/java8-option...

Using option types produces more robust code and prevents null pointer exceptions / segfaults. Go's idiom of multiple return values and error is a poor man's Either, which is an improvement on C's return code idiom[0].

[0] C's return code idiom led to the latest GnuTLS bug:

http://blog.existentialize.com/the-story-of-the-gnutls-bug.h...

Yes, but reading code is much more important than writing it in most contexts, and you're not limited by typing speed anyways.

The one-liner would be harder for me to unpack, in most situations, than a 3-liner. You've got 3 calls, give me space to work with them.

They don't need to be on one line. If you really want to pretend that having them on one line is a problem, then put them each on their own line. You can even be needlessly verbose if you want to:

    do
      a <- GetBar foo
      b <- GetBaz a
      c <- GetCat b
      return c

That's much more to my liking, but still, we've got multiple ways of doing option types and now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them?

I'm not trying to sell anyone, code however you like -- I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs". I bet I can still write bugs.

>now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them?

No. Remember we're talking about using a language that is not broken by design instead of go. You have one operator (>>=) and it works on one typeclass (Monad). Do notation (do and <-) is merely syntactic sugar that desugars to using >>=.

>I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs"

And since those are not the options available, people tell you that those are not the options available. Doing it right is very simple. Your options are "simple and with lots of chances to create bugs" or "just as simple but with fewer chances to create bugs".

Now you've got way less code, and way more cognitive load per line.

To someone who isn't familiar with that particular idiom, perhaps it causes more cognitive load at first. Sometimes you have to learn new ideas and techniques to make the best use of your tools.

On the other hand, once you are familiar with the idiom, what you see there is a concise and easily readable representation of the main algorithm, together with a quickly recognisable, robust way of dealing with the edge cases.

Would you also object to someone using structured programming because it causes way more cognitive load than just writing goto everywhere?

In a language with option types (such as Rust) if you want to be totally explicit and write your error handling the Go way, it's scarcely more verbose than it is in Go, and totally clear:

    let foo = match some_call_that_may_fail() {
        Ok(foo) => foo,
        err => return err,
    };

The advantage is that the language forces you to handle errors: dropping the error on the floor is quite hard to do, whereas "foo, _ = some_call_that_may_fail()" is very easy in Go. (And if the call doesn't return any value at all except an error, you don't even have to write the "foo, _ =" bit; this is a nasty gotcha and is why external lint tools like errcheck are needed for Go.)

I really can't wait to spend more time learning Rust, but that bit you just put out strikes me as a fair bit more complex than just multiple returns plus "don't ignore your errors, dude, you crazy?". We've got the let-match func() {} construction, the Ok() function (built-in? library?), the => foo vs => return err.. that's returning from the outer function, right? Whereas the => foo completes the let and continues? There's a lot going on in there.

I haven't spent any time using Rust, though, so maybe that construction will seem more natural when I get around to doing that.

Anyways, someone upthread called Go 'simplistic' which has both positive and negative connotations, and I totally agree. I'm happy with a simpler setup that solves 80% of problems really well and maybe there are some pitfalls you can fall into if you don't check your error values. As long as I'm not completely hamstrung by the simplicity (generics would be nice), I find the lack of features to be a win when you add up all the non-features that I don't have to think about it.

Go cares about scalability in the large. It doesn't care very much about conciseness in the small.

If you think of it as a big-O problem, you're worried about the coefficient, and Go is worried about the exponent. On a large problem, what Go is worried about solving will matter more. But if you're not on a large problem, that 10% of repetition will chafe you...

>Go cares about scalability in the large

Which features precisely have led you to believe this? I can't see any indication of that anywhere. You seem to be creating a false dichotomy: "caring about abstractions and caring about scalability are opposing goals", so that you can ascribe one side of a nonexistent spectrum to go.

>But if you're not on a large problem, that 10% of repetition will chafe you...

Except that is simply not the case. The larger the problem, the more that duplicate code causes problems.

What led me to believe this is Pike's article about the design goals of Go. I don't know enough about Go to know how well it succeeds, but I know what the intent was.

But you are falsely implying that the intent "be good for big projects" is opposed to the concept of "having useful abstractions". It is not. Go fails at being useful for big projects precisely because it fails to have basic useful abstractions. Those are most important in large projects. In a 1000 line program it doesn't matter much if I am repeating code, there's just not that much code anyways. In a 1000000 line project, it is a serious maintenance problem.

> Yes, you MUST. That is just how Go does things.

If it's something I "must" do, why doesn't the language force it to happen? Silent failure is a really bad default.

You mean something like Java's checked exception? That has its value, but you have some programmers who write empty catch blocks just to get rid of the exception. Forcing the programmer to handle it is not the same as forcing the programmer to handle it.

How is this an argument for silently failing being superior? It seems like static checked exception handling could solve this problem easily, the compiler can just display a warning on an unhandled exception and then pass it up the chain.

It's not an argument for silently failing being superior. It's a claim that too often, static checked exception handling gets subverted, and therefore doesn't work.

Sooner or later, you have to trust the programmer to not be an idiot. If he/she is an idiot, the language can try to help, but can't really fix it.

Static checked exceptions let the programmer know that there's something that needs to be handled. That's good. It can check that the programmer put a catch block somewhere, but it can't guarantee that the programmer did anything appropriate to handle the problem inside that block. It's better than nothing, but it's not enough. (And if you're going to ask what is enough, I have to reply: Nothing. If the programmer is determined to ignore the fact that there's an error to handle, the language can't fix things.)

I can see what you're saying, but ultimately there's no helping people who are doing something they don't really understand. I'm more interested in language features that remind me when I forget to do something I wanted to do.

> That has its value, but you have some programmers who write empty catch blocks just to get rid of the exception.

That's why you have code review and code linters. If you have a linter, there's no way in hell you'll ever miss this has happened.

Take a beginner's Go code ... do they check errors ? Just like with C the answer is plain and simple ... no, they don't.

In my opinion, it should be a compile error to ignore return values without explicitly throwing them away with _.

errcheck will add this as an optional linter. I've adjusted the git hooks on my machine to run errcheck and fail the commit if it doesn't pass (unless I specifically disable it).

add https://github.com/kisielk/errcheck to your continuous integration process.

>Your "unless" is the same as saying in a language like Java

And "our language is just bad as java" is a pretty awful sales pitch.

>That is still probably true, but I don't think its a bad thing.

No it is not a bad thing. It is a terrible thing.

>I attribute this to the fact that we were forced to handle every error.

But you aren't forced, that's the problem.

>Some people like exceptions, but I've always liked Go's way of things in this department.

Some people like proper error signaling and handling instead of either of the broken choices you suggest.

Reply on news.ycombinator.com