from Hacker News

Go 1.1 RC1 is out

by bockris on 5/1/13, 3:08 PM with 117 comments

• by taliesinb on 5/1/13, 6:09 PM

  I'm glad that escape analysis now allows for more natural if/then control flow.

  But I'm still unhappy that using named return values still requires you to put a superfluous "return;" at the end of such a function.

  The whole reason I use named return values is to cut down on the boilerplate code that carries the return value around -- so why not cut out the final boilerplate 'return'? It doesn't solve any problem or add any information!

  Otherwise, there are some nice improvements here. Other than the things mentioned so far, I'm glad to see reflection filling out -- the day a Go REPL will be possible is approaching.

• by dtwwtd on 5/1/13, 3:31 PM

  The race detector sounds interesting:

  http://tip.golang.org/doc/go1.1#race

• by mratzloff on 5/1/13, 8:19 PM

  If we're talking about wishlist items, I'd like a tool, any tool, for detecting memory leaks. I understand they can't use Valgrind itself[1], but as it stands, detecting where leaks exist can be very difficult.

  [1] http://code.google.com/p/go/issues/detail?id=782

• by schoper on 5/1/13, 3:41 PM

  They finally fix:

    func hello() int {
        if true {
            return 0
        } else {
            return 1
        }
    }
  
    >go run func.go
    ./func.go:3: function ends without a return statement

• by CoffeeDregs on 5/1/13, 4:53 PM

  OT: I had not seen that there was a GCC compiler frontend for Go. Does anyone have any experience with that? Do you lose lots of Go specific tooling?

• by kristianp on 5/1/13, 9:12 PM

  Interesting comment in that thread:

  "It's worth mentioning the function representation change, since it means closures no longer require runtime code generation (which among other things allows the heap to be marked non-executable on supported systems)."

  Anyone know what that means?

• by ngoldbaum on 5/1/13, 8:47 PM

  Right now it's hard to do numerical analysis on large problems using Go. To fix that, I'd be really excited to see bindings for MPI or something like it. In particular, go doesn't have a concept of an Allreduce or an AllToAll communication. I know that one can do that by calling the C MPI bindings from go, but it would be cool if there were a natural way to do it using go's parallelism and concurrency patterns.

  It would also be nice to have a first-class array object - from what I understand, current support for multidimensional arrays is very C-like in that you're really dealing with pointer arrays.

• by bbrunner on 5/1/13, 4:55 PM

  I haven't made the jump to using any of the 1.1 betas or this RC but the reported 30-40% performance bumps look nice. I'm really still waiting for an easy way to get gccgo working on os x though.

  And I'm glad that they're bumping up the heap size to system-dependent values on 64bit systems. The fixed heap size of 16 GB was a really unfortunate constraint (even if it could be changed with a little hacking around).

• by ameen on 5/1/13, 7:08 PM

  Go noob here

  Can actual products (Web apps in my case) be built with Go?

• by knodi on 5/1/13, 4:50 PM

  What about the 8 remaining issues http://swtch.com/~rsc/go11.html will they be part of the Go 1.1 final?

• by timothya on 5/1/13, 3:21 PM

  I guess this website is going to have to change soon: http://isgo1point1outyet.com/

• by pstuart on 5/1/13, 8:18 PM

  Solaris support would be nice...