Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When in Go, do as Gophers do

talks.golang.org

Post reply on HN
Print view View original

51–60 of 93 posts

Re: When in Go, do as Gophers do

#51

Post by dyadic »

wolf550e wrote: post #38
dyadic wrote: post #30

I've only been using Go for less than a week and my impressions are less than good. I'm still waiting and hoping to understand what it is that people like about Go, but I'm starting to suspect that won't happen. The biggest problem I have had most so far is when reading other code, finding the meaning amongst all of the error nil checks and the sprawling if conditions that they bring. Another thing that makes it diff…

That is the way it is done in C: avoid indentation if you can fail out. It is very readable.

I disagree, and saying "That is the way it is done in C" doesn't mean that it's the right way.

When I see code like this I will assume that it's going to check every condition:

        if !complete {
            // do something
        }
        if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 {
            // do something
        }
        if r.Created {
            // do something
        }
If the first condition matching causes the second, third, nth condition to not be checked then why not make it clear in the code by adding an `else`?

The recommended way means that I can't trust my assumption and that I'll have to read the entire function and examine the `//do something`s instead

Re: When in Go, do as Gophers do

#52

Post by tptacek »

dyadic wrote: post #51
wolf550e wrote: post #38

Earlier quoted context omitted.

That is the way it is done in C: avoid indentation if you can fail out. It is very readable.

I disagree, and saying "That is the way it is done in C" doesn't mean that it's the right way. When I see code like this I will assume that it's going to check every condition: if !complete { // do something } if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 { // do something } if r.Created { // do something } If the first condition matching causes the second, third, nth condition to not be checked then wh…

If you are religious about single-return style --- and I was an observant practitioner of it until recently --- you simply aren't going to like Golang.

For that matter, if you hate C programming --- not in the sense of "C is dangerous and error prone" and more in the sense of "I hate the way I feel when I write C code", you also aren't going to like Golang.

The former issue grinds on me a bit, though I'm coming to appreciate what it does for the reliability of my code versus languages with exceptions. On the other hand, I love writing C code, and that probably makes up for it.

Re: When in Go, do as Gophers do

#53

Post by lclarkmichalek »

sagichmal wrote: post #50
lclarkmichalek wrote: post #34

Earlier quoted context omitted.

Given that every single error check there is just passing up the error, is it really that different from having exceptions that propagate along with RAII style resource cleanup? The vast vast vast majority of Go code simply propagates errors.

> Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling le…

Except, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.

Re: When in Go, do as Gophers do

#54

Post by zzzcpan »

dyadic wrote: post #30

I've only been using Go for less than a week and my impressions are less than good. I'm still waiting and hoping to understand what it is that people like about Go, but I'm starting to suspect that won't happen. The biggest problem I have had most so far is when reading other code, finding the meaning amongst all of the error nil checks and the sprawling if conditions that they bring. Another thing that makes it diff…

Yes, this is a really bad abstraction that was yanked from its context and made code really hard to follow and understand which will lead to a bug someday. But we don't have to follow his advise on this and are better off keeping our code sane.

Re: When in Go, do as Gophers do

#55

Post by lclarkmichalek »

NateDad wrote: post #33
zimbatm wrote: post #21

Earlier quoted context omitted.

Go's error handling works well in small programs but there's a couple of issues. One is that it quickly becomes hard to find out where errors really came from. Consider this idiomatic code: func MyFunc(input int) (output int, err error) { if output, err = someOtherFuncA(input); err != nil { return } if output, err = someOtherFuncB(output); err != nil { return } // ... } If MyFunc returns an error it's not possible to…

That's not really idiomatic. You should be adding context to the error you return, or a new error.

Given its prevalence all across Go code, are you _sure_ it's not idiomatic? Hell, look at the presentation in the link: http://talks.golang.org/2014/readability.slide#11. If the oracle of idioms does not write idiomatic code, then wtf is idiomatic code?

Re: When in Go, do as Gophers do

#56

Post by Karunamon »

frou_dh wrote: post #40
4ydx wrote: post #14

Earlier quoted context omitted.

Feel free to enlighten us specifically about how they are better.

In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.

What's the practical problem of this, though? The (varname, err := thing) pattern is sprinkled all throughout the language, enough to where it should be instinctive for a coder to check the err value when doing anything that could fail.

Re: When in Go, do as Gophers do

#57

Post by mostafah »

sanswork wrote: post #2

I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.

Or, it could be a result of Go making use of some novel approaches that a lot of programmers are not used to.

Re: When in Go, do as Gophers do

#59

Post by frou_dh »

Karunamon wrote: post #56
frou_dh wrote: post #40

Earlier quoted context omitted.

In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.

What's the practical problem of this, though? The (varname, err := thing) pattern is sprinkled all throughout the language, enough to where it should be instinctive for a coder to check the err value when doing anything that could fail.

Of course we can put up with anything. The topic of the subthread is that it's halfassed and has a better alternative.

Re: When in Go, do as Gophers do

#60

Post by jshen »

Karunamon wrote: post #56
frou_dh wrote: post #40

Earlier quoted context omitted.

In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.

What's the practical problem of this, though? The (varname, err := thing) pattern is sprinkled all throughout the language, enough to where it should be instinctive for a coder to check the err value when doing anything that could fail.

A major hit to readability. Every call site where you want to check for an error requires adding another level of nesting.
Post reply on HN