When in Go, do as Gophers do • Hacker News Board

Re: When in Go, do as Gophers do

#91

Post by mratzloff » Mon, Dec 08, 2014, 7:28 PM UTC

steveklabnik wrote: post #18

mratzloff wrote: post #8

I found that I already do all of these as a result of reading through a lot of the Go standard library when I was learning it. One of the best ways to really learn a language is to read the standard library (the parts implemented in that language, anyway). That way you get a sense of the idioms used, but also understand the sometimes subtle trade-offs of common functions.

This can be both good and bad. Two examples: The Rust standard library has/had lots of awkward bits, from when certain language features didn't yet exist, or before there was a convergence on how to accomplish something idiomatically. The Ruby standard library has tons of Ruby code in it that's 20 years old, that nobody has touched for various reasons. I certainly wouldn't write Ruby in the same way.

Yeah. When I learned Ruby I read the Rails code base, which comes with its own set of issues, but which was more modern and was a better representation of the current state of Ruby.

Re: When in Go, do as Gophers do

#92

Post by mratzloff » Mon, Dec 08, 2014, 7:37 PM UTC

zimbatm wrote: post #21

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

> Go's error handling works well in small programs but there's a couple of issues.

It works fine in big programs, too. If you need more context, you add custom errors that have a context field. If you need to match different types of errors, you can have an error code that you can check against, or you can simply match strings (a lot of Go code does this). What you see as a problem is not really much of a problem in practice for well-structured code.

Re: When in Go, do as Gophers do

#93

Post by lazzlazzlazz » Sun, Dec 14, 2014, 2:37 AM UTC

masklinn wrote: post #12

gorhill wrote: post #11

Earlier quoted context omitted.

> more modern languages which use return values for error signaling I must be missing something.. Returning a value in Go for error signaling is the way to signal errors in Go.

> I must be missing something.. Returning a value in Go for error signaling is the way to signal errors in Go. Yes? That's the point, I'm comparing it to more modern languages which signal error "the same way", by opposition to languages implementing different high-level methods of error signaling. The clause is there to explicitly point out that I'm not considering or talking about exceptions and conditions-based er…

Yeah, I parsed this incorrectly as well. It was an ambiguous statement.

You posted a while back that "scope inference (in Python) sucks". Could you expand on that. I know it's totally unrelated to this thread but I was really hoping to understand what you meant.

Thanks!