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

Twelve Go Best Practices

talks.golang.org

Post reply on HN
Print view View original

41–50 of 153 posts

Re: Twelve Go Best Practices

#41

Post by dragonwriter »

srpablo wrote: post #32
ktt wrote: post #23

Interesting that this snippet: func (g *Gopher) DumpBinary(w io.Writer) error { err := binary.Write(w, binary.LittleEndian, int32(len(g.Name))) if err != nil { return err } _, err = w.Write([]byte(g.Name)) if err != nil { return err } err = binary.Write(w, binary.LittleEndian, g.Age) if err != nil { return err } return binary.Write(w, binary.LittleEndian, g.FurColor) } could be written like this: func (g *Gopher) Dum…

/pedant hat on Technically, the language does support exceptions. That said, they're in the "please never use this, ever." /pedant hat off The spirit of your comment is right, however -- the wonky code resulting from error handling, just like the "compile error on unused vars or imports," is something most new Go users find jarring.

> Technically, the language does support exceptions. That said, they're in the "please never use this, ever."

No, its not. The convention is that any use of panics within libraries should be internal, and that libraries' exposed interfaces should use error returns. [1] Use of panics internal to libraries, or use of panics within application code that is not creating a library for others to consume, is not discouraged.

[1] http://blog.golang.org/defer-panic-and-recover

Re: Twelve Go Best Practices

#42

Post by buerkle »

freyr wrote: post #29
dragonwriter wrote: post #13

Earlier quoted context omitted.

> Didn't read, because mouse scroll wheel doesn't work. You don't need the scroll wheel to navigate the presentation. Click on the right side of the slide to go forward, on the left side to go back. > Honestly, who thinks this stuff is a good idea? People who are making presentations to deliver in an in-person setting where putting them on the web for everyone is a secondary use, not the primary use? I mean, looking…

Also, you can use the arrow keys to go back and forth through the slides.

Yes all those options work. But why remove a common method of navigation? In addition, the format makes it impossible to search for text within the presentation.

Re: Twelve Go Best Practices

#43

Post by frou_dh »

bradfitz wrote: post #35
frou_dh wrote: post #26

Something that doesn't sit right with me is the use of a "channel of bool" when the receiving goroutine doesn't actually care whether true or false is sent. It muddies the API to force the sender to choose one of two values when all that's really wanted is an amorphous signal. e.g. in http://talks.golang.org/2013/bestpractices.slide#25 , the first case in the select will trip regardless of which value arrives, yet th…

Just sending "true" as a signal is a convention, but some people prefer something like http://play.golang.org/p/oXapo7R4RX

Cool, I like that. In some ways, it would be nice if there were a friendly alias for struct{} as part of the language, but I suppose it's hard to come up with a good general name for that.

Re: Twelve Go Best Practices

#44

Post by dragonwriter »

shurcooL wrote: post #31
frou_dh wrote: post #26

Something that doesn't sit right with me is the use of a "channel of bool" when the receiving goroutine doesn't actually care whether true or false is sent. It muddies the API to force the sender to choose one of two values when all that's really wanted is an amorphous signal. e.g. in http://talks.golang.org/2013/bestpractices.slide#25 , the first case in the select will trip regardless of which value arrives, yet th…

A channel may be closed with the built-in function close; the multi-valued assignment form of the receive operator tests whether a channel has been closed. [1] Given that is available, why is the use of a separate bool quit channel preferred? [1] http://golang.org/ref/spec#Channel_types

A quit channel (that is not receive only) can be used to send back a quit message by a goroutine that only has a receive-only view of the main data channel; close() can't be called on a receive-only channel.

Re: Twelve Go Best Practices

#45

Post by frou_dh »

shurcooL wrote: post #31
frou_dh wrote: post #26

Something that doesn't sit right with me is the use of a "channel of bool" when the receiving goroutine doesn't actually care whether true or false is sent. It muddies the API to force the sender to choose one of two values when all that's really wanted is an amorphous signal. e.g. in http://talks.golang.org/2013/bestpractices.slide#25 , the first case in the select will trip regardless of which value arrives, yet th…

A channel may be closed with the built-in function close; the multi-valued assignment form of the receive operator tests whether a channel has been closed. [1] Given that is available, why is the use of a separate bool quit channel preferred? [1] http://golang.org/ref/spec#Channel_types

In the link, the quit is acknowledged, so one side closing the channel straight off the bat wouldn't allow for that.

Re: Twelve Go Best Practices

#46

Post by lazyjones »

nknighthb wrote: post #3

if err == nil { _, err := w.Write([]byte(g.Name)) if err == nil { err := binary.Write(w, binary.LittleEndian, g.Age) if err == nil { return binary.Write(w, binary.LittleEndian, g.FurColor) } return err } return err } Why does anyone have to tell people not to do this? How does it enter anyone's mind as a thing to do in the first place? I've been known to go too far to minimize nesting. I get twitchy at the second lev…

People end up doing this because code gets written incrementally and often we start out wrong (e.g. here with the wrong/inverted condition). Rewriting large code blocks for a little more clarity is often a PITA.

It would help very much if editors supported this better (e.g. single keystroke inversion of an "if"). Go with its easy syntax would be a particularly good target for automatic rewrites for code like the above, or even just editor-level hints for better style.

Re: Twelve Go Best Practices

#47

Post by llimllib »

joshuaellinger wrote: post #39

Odd choice of examples... 1. The file I/O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain't it. 2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn't support overloading. Again, looks more lik…

Presumably these are tips for coders, not for language developers. As such, the language has neither generics nor exceptions and the programmer has to deal with that.

> is the "break;" implicit in Go?

Yes. http://golang.org/doc/effective_go.html#switch

Re: Twelve Go Best Practices

#48

Post by bcgraham »

joshuaellinger wrote: post #39

Odd choice of examples... 1. The file I/O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain't it. 2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn't support overloading. Again, looks more lik…

W/r/t #2 - you're not familiar with Go but knew exactly what was going on. That's totally a feature. The language was designed around exactly that kind of reading.

"break;" is implicit in Go.

Re: Twelve Go Best Practices

#49

Post by Arzh »

joshuaellinger wrote: post #39

Odd choice of examples... 1. The file I/O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain't it. 2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn't support overloading. Again, looks more lik…

yes a switch will not fallthough unless you tell it manually http://golang.org/ref/spec#Fallthrough_statements

Re: Twelve Go Best Practices

#50

Post by icebraining »

zeeboo wrote: post #38
rorrr2 wrote: post #34

Holy shit that function adapters example is convoluted. I'd say fewer than 5% of my programmer coworkers would figure out what's going on. func init() { http.HandleFunc("/", errorHandler(betterHandler)) } func errorHandler(f func(http.ResponseWriter, *http.Request) error) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { err := f(w, r) if err != nil { http.Error(w, err.Error(), http.StatusInter…

Less than 5% of your coworkers understand decorators? I don't want to sound snooty but this is a pretty trivial application of higher order functions.

I have to agree; it's basic stuff even for a Python weenie like me.
Post reply on HN