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

41–50 of 93 posts

Re: When in Go, do as Gophers do

#41

Post by [deleted] »

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.

[deleted]

Re: When in Go, do as Gophers do

#42

Post by skrebbel »

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.

I think that's a good thing. If Scala had a better commonly accepted idea of what's "idiomatic Scala", then maybe the "there's more than 6497492 ways to do it" stigma that Scala's recently gotten might've been avoided.

You need discussion about what's considered "good" before you can arrive at a relatively common opinion about that.

Re: When in Go, do as Gophers do

#43

Post by aikah »

brian_herman wrote: post #4
bsaul wrote: post #3

Earlier quoted context omitted.

this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.

I think small is a good thing in languages for example the C programming language is very simple in the language but very powerful. Simplify Simplify Simplify.

> Simplify Simplify Simplify.

Yet C programmers use shitloads of macros to make up for C lack of features.

Re: When in Go, do as Gophers do

#45

Post by howeman »

4ydx wrote: post #14
masklinn wrote: post #10

Earlier quoted context omitted.

Go's error handling remains verbose, unsafe and error-prone compared to more modern languages which use return values for error signaling (Erlang, MLs, Haskell, Rust). The problem is not that Go's error handling requires more thinking or efforts, it's that it is bad , and while that's an improvement from C's terrible error handling it's still nowhere near good enough, let alone good (unless you consider C's error han…

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

> You're not returning a sum type so it's down to convention to remember that the "real" return value is effectively garbage when the error return value is non-nil.

There are many cases where this is not true.

Re: When in Go, do as Gophers do

#46

Post by howeman »

pjmlp wrote: post #32
webtopaz wrote: post #23

Earlier quoted context omitted.

It is a perfectly reasonable way to test for interfaces. A single struct may satisfy a hundred interfaces which it doesn't even know about, this is actually one of the best traits of go.

No, it is a workaround pattern due to lack of language support.

You understand that the satisfaction is verified at compile time, right?

Re: When in Go, do as Gophers do

#47

Post by webtopaz »

bsaul wrote: post #31
webtopaz wrote: post #29

Earlier quoted context omitted.

This is how you can make sure that a struct implements an interface. The line 'var _ scan.Writer = (*ColumnWriter)(nil)' assigns a nil pointer of the struct to a scan.Writer interface reference which would fail if ColumnWriter doesn't implement the interface. And the casting always works.

So it's a static typing check ? the code won't even compile if the ColumnWriter struct doesn't implement the interface ?

Yes. It won't compile.

This check is not really needed as the code would fail when a function which accepts scan.Writer would fail (compilation) if ColumnWriter is sent and if it doesn't satisfy the interface. However, this is easier to debug.

Re: When in Go, do as Gophers do

#48

Post by thrill »

userbinator wrote: post #37
myg204 wrote: post #13

Earlier quoted context omitted.

> I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). C++11 and C++14 also have a lot of idiomatic discussion since the community's trying to move to a different style with the latest enhancements. Not sure if this is a signal of core issues.

Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). I wonder what an appropriate adjective could be for idiomatic Go code. Gonic? Gonian?

Gonic - causing a desired reaction - might work, though I suppose any correct code would fit that definition. I sort of like gothic - always recognizable, consistent, big.

Re: When in Go, do as Gophers do

#49

Post by _blob »

lukasm wrote: post #44

I don't get where is the bug in this code: http://talks.golang.org/2014/readability.slide#10

In the original code if out.Close() returns an error, run() will return nil. The revised code sets `err` to the returned error from out.Close(), in case the error from os.Create(*output) is nil.

Simply spoken, the original code will suppress the error from out.Close().

Re: When in Go, do as Gophers do

#50

Post by sagichmal »

lclarkmichalek wrote: post #34
libria wrote: post #28

Earlier quoted context omitted.

In Java, I'd have to write 3 catch blocks. It's possible to write a blanket catch, toss it up to higher levels and make it someone else's problem. I vaguely recall this being against Pike's vision of what "exceptional" means and he wanted a language that forces developers to think of disk/network failure as a very common case.

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 less verbose, but hiding it altogether would subvert that explicit language design goal.
Post reply on HN