Live data from Hacker News

When in Go, do as Gophers do

talks.golang.org

11–20 of 93 posts

Re: When in Go, do as Gophers do

#11

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…

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

Re: When in Go, do as Gophers do

#12
post #11

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…

> 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 error signaling.

Maybe it'd have been clearer if I'd written "languages which also use return values"?

Re: When in Go, do as Gophers do

#13
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'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.

Re: When in Go, do as Gophers do

#14

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…

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

Re: When in Go, do as Gophers do

#15
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.

Heh... I had a similar thought back when I was using Python. In both cases, I don't think it's a matter of the language "fighting" you. You can write Go however you like, so long as it compiles and runs. However, it IS a matter of people on the Internet mocking you for not being "pythonic".

Re: When in Go, do as Gophers do

#17
I'm on Chrome on Mac and it's not entirely obvious how to navigate these slides. Going to the link only shows me the first 3 slides by scrolling right.

Playing around a bit, I discovered that the arrow keys bring you to the next slides. Perhaps there could be a way to make that more obvious, or provide buttons onscreen.

Re: When in Go, do as Gophers do

#18

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.

Re: When in Go, do as Gophers do

#19
post #13
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'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.

We Ruby programmers also obsess over style, especially with regards to tests. There's even a full, printed book about it: "Eloquent Ruby."
Post reply on HN