Hacker News Reader

Comment by lmm | Hacker News Reader

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).

View on HN

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.

Reply on news.ycombinator.com