Six years of Go

Post by vorg » Tue, Nov 10, 2015, 10:13 PM UTC

vruiz wrote: post #210

lobster_johnson wrote: post #193

Earlier quoted context omitted.

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

> If you have "func bar() (MyStruct, error)", you cannot do "foo(bar())". You must always assign the result to an intermediate variable. You could embed the error in the MyStruct struct instead, but that goes against Go's grain. Chaining does work, but obviously the function needs the same signature as the return values, which limits things since most APIs don't accept errors as input. But within your code you can st…

  package main
  import "fmt"

  func foo(a ...interface{})interface{}{
    if len(a) == 0 {
      return nil
    } else if len(a) == 1 {
      return a[0]
    } else {
      return a
    }
  }

  func barbar() (a, b int) { return 1, 2 }
  func bar() (a int) { return 1 }
  func baz() { return }

  func main() {
    fmt.Println( foo(barbar()) ) // prints: [1, 2]
    fmt.Println( foo(bar()) )    // prints: 1
    fmt.Println( foo(baz()) )    // compile error: baz() used as value
  }

Post by pkates » Tue, Nov 10, 2015, 10:34 PM UTC

lobster_johnson wrote: post #232

deepanchor wrote: post #174

Earlier quoted context omitted.

I've found the standard library to be more than capable for most CRUD style apps. You can add in simple middleware chaining using a library such as Alice ( https://github.com/justinas/alice ) and for passing around request contexts between them, you can use something like xhandler ( https://github.com/rs/xhandler ). If you want more performant or flexible routing, httprouter ( https://github.com/julienschmidt/httprou…

That's the libraries I use, too. I really wish contexts were built into Go's HTTP library. Without contexts, you have to use global variables to accomplish things like per-request logging and access to configuration data. Not to mention that since goroutines cannot be forcibly terminated, it's the only way to control the lifetime of a handler (e.g. applying timeouts).

Post by forgotAgain » Tue, Nov 10, 2015, 10:52 PM UTC

jonesb6 wrote: post #244

lobster_johnson wrote: post #193

Earlier quoted context omitted.

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

If there a paradigm for handling multiple potential errors in a function? I'm usually stuck using: reply, err := redis.Givemethevalue(key) if err != nil { return err } thing, err2 := postgres.getById(reply) if err2 != nil { return err2 }

  var err error

Post by aikah » Tue, Nov 10, 2015, 10:56 PM UTC

jonesb6 wrote: post #236

I've used Go for a couple years but am only just writing my first production system in Go. I think one of the major complaints is that it's use-cases are ambiguous to beginners. Go, IMO, is a systems language and should not be the first thing you pull out when someone says "write a web app". I think Go has a very limited use case, but it is incredibly good for that use case. If I had to define it right now it would b…

Post by tptacek » Tue, Nov 10, 2015, 10:59 PM UTC

lobster_johnson wrote: post #193

matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…