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

31–40 of 153 posts

Re: Twelve Go Best Practices

#31

Post by shurcooL »

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

Re: Twelve Go Best Practices

#32

Post by srpablo »

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.

Re: Twelve Go Best Practices

#33

Post by jamesaguilar »

Thirteen: don't try to sort, it's going to be painful if you do.

http://golang.org/pkg/sort/ (See example 1 -- you have to write that for every concrete slice type you want to sort; it's not enough to write it once. And god help you if you also want to sort other collection types.)

Re: Twelve Go Best Practices

#34

Post by rorrr2 »

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.StatusInternalServerError)
                log.Printf("handling %q: %v", r.RequestURI, err)
            }
        }
    }

    func betterHandler(w http.ResponseWriter, r *http.Request) error {
        if err := doThis(); err != nil {
            return fmt.Errorf("doing this: %v", err)
        }

        if err := doThat(); err != nil {
            return fmt.Errorf("doing that: %v", err)
        }
        return nil
    }

Re: Twelve Go Best Practices

#35

Post by bradfitz »

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

Re: Twelve Go Best Practices

#36

Post by dragonwriter »

shurcooL wrote: post #28
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…

If the language supported exceptions, how would you write this func? func (g *Gopher) DumpBinary(w io.Writer) { // Ignore all errors _ = binary.Write(w, binary.LittleEndian, int32(len(g.Name))) _, _ = w.Write([]byte(g.Name)) _ = binary.Write(w, binary.LittleEndian, g.Age) _ = binary.Write(w, binary.LittleEndian, g.FurColor) }

The language supports exceptions (panics). You could do something like (this is untested code):

  func panicBinaryWrite(w io.Writer, b binary.ByteOrder, data interface{}) {
    if err := binary.Write(w, b, data); err != nil {
      panic("Error in binary.Write")
    }
    return
  }

  func panicWrite(w io.Writer, data interface{}) {
    if _,err := w.Write(binary.LittleEndian,data); err != nil {
      panic("Error in io.Writer#Write")
    }
    return 
  }

  func ignoreErrors(f func()) {
    defer func() { 
      _ = recover()
    }()
    f()
    return
  }

  func (g *Gopher) DumpBinary(w io.Writer) {
    // Ignore all errors
    ignoreErrors(panicBinaryWrite(w, binary.LittleEndian, int32(len(g.Name))))
    ignoreErrors(panicWrite([]byte(g.Name)))
    ignoreErrors(panicBinaryWrite(w, binary.LittleEndian, g.Age))
    ignoreErrors(binary.Write(w, binary.LittleEndian, g.FurColor))
  }

Re: Twelve Go Best Practices

#37

Post by conroy »

campoy wrote: post #22
conroy wrote: post #4

Meta comment: does anyone know what software is used to generate these slides? I've seen a few slide decks in the same format and they're impossible to use on mobile. I'd like to fix that

Hi, I created these slides using code.google.com/p/go.talks You can actually find the source code and the slides in it.

Thanks for the link. I'll take a look and see if I can make it work better on mobile.

Re: Twelve Go Best Practices

#38

Post by zeeboo »

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.

Re: Twelve Go Best Practices

#39

Post by joshuaellinger »

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 like a bug than a feature.

Also, is the "break;" implicit in Go? At first glance, it looks like a coding error.

Re: Twelve Go Best Practices

#40

Post by rorrr2 »

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 guess I work a lot with average developers. Not every corp is Google.
Post reply on HN