1. 18
    Go at Google (Slides by Rob Pike) go talks.golang.org
    jcs avatar via jcs 5 years ago | cached | 8 comments

  1.  

  2. 2
    steveklabnik avatar steveklabnik 5 years ago | link

    So Go kinda intrigues me, but two things:

    1. Google. This is a pretty big drawback for me, personally.
    2. While structural typing seems good to me, I’ve been on the extremes too long; full-on duck typing or crazy Haskell static typing seems to fit my brain better. Dunno about this one, either.

    So, Go fans, I know there’s a lot of you here. Pitch me: why’s Go super rad?

    1. 3
      kyle avatar kyle 5 years ago | link

      I have to note that I haven’t really seen much of Google in this. I think that it has reached its own momentum at this point.

      Here’s a few things I love:

      1. Built in, extremely easy concurrency with channels and goroutines. CSP isn’t the only way to do concurrency (see Erlang, for example) but they have made their choice and done well with it.
      2. The compiler is extremely fast, and you have the benefit of compiled code instead of running on top of a VM or interpreter.
      3. There is a rich standard library.

      It’s a little early in the morning, so I’ll probably start adding more stuff later.

      1. 2
        steveklabnik avatar steveklabnik 5 years ago | link

        I do really, really, really, really love the idea of gofmt.

        1. 2
          kyle avatar kyle 5 years ago | link

          I have this as a precommit hook in my projects as the last step – if everything builds, it is formatted properly before being committed. I find this to be quite a useful way to ensure I meet the standard.

          One thing I liked about Python (even if I disagreed with some aspects) was PEP 8 and having tools such as the eponymous tool to check for violations and pylint.

        2. 2
          trousers avatar trousers 5 years ago | link

          Adding to what Kyle said, I also like the following:

          • functions can be tied to data (struct, custom-type, etc)

          • composition over inheritance. You compose data via embedding, instead of inheriting like in traditional OO systems (at least those I have been familiar with). This seems more right to me. I feel like I am constructing/building things I need/want, instead of creating taxonomies. I find this also seems to make refactoring a bit more straightforward for me.

          • interfaces are more of ‘has a’ vs ‘is a’ type checking. By this I mean a type fulfills an interface if it has the right functions, as apposed to having the right class graph. This ties in with composition to make things nicely reusable.

          • io is async but blocking (it blocks only the goroutine). This makes code easy (for me) to reason about. It has a similar feel to python+gevent coroutines to me.

          • go fmt is indeed awesome.

          1. 2
            kyle avatar kyle 5 years ago | link

            I feel like I am constructing/building things I need/want, instead of creating taxonomies.

            I also love how it feels like there is a lot less boilerplate. The one exception is the

            if foo, err = someCall(); err != nil {
    // handle error
} else ...

            constructs you see everywhere. I’ve found that to be less painful over time, and to be a good way of checking my assumptions while writing code v. while running it.

            1. 2
              trousers avatar trousers 5 years ago | link

              Yeah, the error handling is verbose and a bit boilerplate. It seems to at least read well, and blend into the code fairly evenly. It is usually a bit easier to spot code not handling errors well too, which is a nice change from my experience with exceptions where I often have to hunt around to see where the exception may percolate up to.

              1. 1
                kyle avatar kyle 5 years ago | link

                It is; but it comes with a bonus: if you want to pass errors up the call stack, you can:

                func Top() (success bool) {
    // declare for scoping
    var val int
    var err error
    if val, err = Mid(); err != nil {
        // any additional error checking and handling
        success = false
    } else if val != MagicNumber {
        success = false
    } else {
        success = true
    }
    return
}

func Mid() (val int, err error) {
    // ...
    if val, err = Low(err); err != nil {
        return
    }
    // do something with val maybe
    return
}

func Low() (val int, err error) {
    if val, err = Foo(); err != nil {
        return
    }
    // do something with val maybe
    return
}