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

71–80 of 93 posts

Re: When in Go, do as Gophers do

#71

Post by burntsushi »

masklinn wrote: post #10
mratzloff wrote: post #6

Earlier quoted context omitted.

If you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling. I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.

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…

Saying that a particular language feature is bad in a vacuum is a ridiculous endeavor because you aren't accounting for trade offs in the language as a whole. The most obvious way to "fix" Go error handling is to add some form of sum types to the language. But this comes with its own set of trade offs that have been discussed at great length on golang-nuts.

Re: When in Go, do as Gophers do

#72

Post by jmnicolas »

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?

How about Gothic ?

Re: When in Go, do as Gophers do

#73

Post by tptacek »

dyadic wrote: post #68
tptacek wrote: post #52

Earlier quoted context omitted.

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 ap…

I suspect you're right. I'm going to continue with Go for a little while longer to give it a real chance, there are a few things I like about it such as the dependency management and the lightning fast compilation so there's still a chance that I will grow to like it.

I really hate Golang error handling, but I have to grudgingly acknowledge that it results in code that is more reliable than Ruby or Python (and much more reliable than C). That's a dividend paid by explicitness.

I would not say I've grown to like the error handling, but when I trudge through it now, I do so realizing that there's probably an actual benefit to my program of the annoyance.

The Go standard library is also really, really well designed.

Re: When in Go, do as Gophers do

#74

Post by frou_dh »

jbooth wrote: post #70
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.

Wait, that's it? The difference between bad (with italics!) and awesome is being able to reference the garbage half of a multiple return?

I'm not the GP. Ask them for their full story.

Re: When in Go, do as Gophers do

#75

Post by pjmlp »

howeman wrote: post #46
pjmlp wrote: post #32

Earlier quoted context omitted.

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

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

Sure I do.

Other languages provide constructs to check for interface compliance, Go requires writing dummy code.

Re: When in Go, do as Gophers do

#76

Post by [deleted] »

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…

[deleted]

Re: When in Go, do as Gophers do

#77

Post by burntsushi »

pjmlp wrote: post #75
howeman wrote: post #46

Earlier quoted context omitted.

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

Sure I do. Other languages provide constructs to check for interface compliance, Go requires writing dummy code.

Go does not require it. Interface compliance is statically checked.

This is a debugging trick because Go interfaces use structural subtyping instead of explicitly declaring which types implement an interface. This is a calculated design decision with several trade offs. There is nothing "sad" about it.

Re: When in Go, do as Gophers do

#78

Post by wting »

jbooth wrote: post #70
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.

Wait, that's it? The difference between bad (with italics!) and awesome is being able to reference the garbage half of a multiple return?

You can embed metadata with sum types on a return object. You can then use the metadata programmatically to increase correctness, enhance readability, and reduce boilerplate. This blog post goes into more details:

http://fsharpforfunandprofit.com/posts/recipe-part2/#series-...

Re: When in Go, do as Gophers do

#79

Post by pjmlp »

burntsushi wrote: post #77
pjmlp wrote: post #75

Earlier quoted context omitted.

Sure I do. Other languages provide constructs to check for interface compliance, Go requires writing dummy code.

Go does not require it. Interface compliance is statically checked. This is a debugging trick because Go interfaces use structural subtyping instead of explicitly declaring which types implement an interface. This is a calculated design decision with several trade offs. There is nothing "sad" about it.

How do you list all interfaces a give type supports just by looking at it?

Both by design, as well as, by accident (usually it different method semantics).

You don't need to teach me Go, I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.

Re: When in Go, do as Gophers do

#80

Post by burntsushi »

pjmlp wrote: post #79
burntsushi wrote: post #77

Earlier quoted context omitted.

Go does not require it. Interface compliance is statically checked. This is a debugging trick because Go interfaces use structural subtyping instead of explicitly declaring which types implement an interface. This is a calculated design decision with several trade offs. There is nothing "sad" about it.

How do you list all interfaces a give type supports just by looking at it? Both by design, as well as, by accident (usually it different method semantics). You don't need to teach me Go, I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.

> How do you list all interfaces a give type supports just by looking at it?

By design, you can't.

> You don't need to teach me Go

Then don't state patently false claims. "Other languages provide constructs to check for interface compliance, Go requires writing dummy code." This is false because interface compliance is checked statically. This is orthogonal to whether you can list all interfaces satisfied by a given type.

> I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.

That's not a feature unique to gonuts. If you disagree with a project's fundamental design and stated goals, then I'm not sure what else you might expect.

For example, I'm not particularly interested in the JVM/Java world due to a myriad of design decisions that they've made. But I don't go around trolling the Internet with near content-free comments and inaccurate statements about their ecosystem.

Post reply on HN