
Go 1.3 is released - enneff
http://blog.golang.org/go1.3
======
Scaevolus
The static analysis features are exciting:
[http://golang.org/lib/godoc/analysis/help.html](http://golang.org/lib/godoc/analysis/help.html)

"Because concurrent Go programs use channels to pass not just values but also
control between different goroutines, it is natural when reading Go code to
want to navigate from a channel send to the corresponding receive so as to
understand the sequence of events.

Godoc annotates every channel operation—make, send, range, receive, close—with
a link to a panel displaying information about other operations that might
alias the same channel."

Understanding large concurrent programs is significantly easier with a precise
pointer analysis to help you track objects.

~~~
amerine
This is wonderful.

------
nkozyra
GC changes are probably most exciting ( deference to the support for Plan 9 ;)
)

I still can't tell if it's evolved beyond a mark-and-sweep - I have to assume
no - we've heard the GC would be seeing improvements and that the current (now
older) method was stop-gap.

~~~
4ad
Minor note. Go had some form of Plan 9 support for years, mostly broken
though, we just made it much much better this release.

~~~
nkozyra
I would have assumed Plan 9 would have been supported in some capacity for
obvious reasons,

------
frakturfreund
The release notes mention the graceful shutdown of a http.Server:

"The net/http package now provides an optional Server.ConnState callback to
hook various phases of a server connection's lifecycle (see ConnState). This
can be used to implement rate limiting or graceful shutdown."

Knows anyone here a code example for this?

~~~
dchest
[https://github.com/rcrowley/go-
tigertonic/compare/go1.3](https://github.com/rcrowley/go-
tigertonic/compare/go1.3)

------
lbotos
Current Go users, What's the state of package versioning right now? Is
vendorization still the answer?

~~~
dayjah
We use Godep, it is very good. As per another answer to your question: with
'-copy=false' it behaves a lot like bundler.lock. Having spent a lot of time
working with it we've found a few areas where you can get burned a little;
particularly if you've structured your repos as a set of libraries, as seems
to be the encouraged golang pattern.

When you have multiple libraries you have to be very specific about when you
run godep, lest you find yourself with two libraries needing different
versions of a common library, for example Main imports Foo and Bar, which both
import Baz. Godep provides a mechanism for handling this: each dependency is
explicitly locked into a fixed revision (e.g. commit sha, in the case of git).
The pain comes about when during debugging as it can be very hard to reason
which version of a library you're using.

Additionally the revision aspect is also a bit of a PITA, we use a development
flow which rebases our small commits into a big commit and then merges that
into our master branch; if you ran godep prior to that you're now referencing
a commit that no longer exists. Given the chain of references that can exist
this can go a very long way down. This same pattern also forces you into
needing to push your dev branches to an origin server, as godep checks out the
repos during the build, which while pretty benign a concern is a PITA if you
forget and your build breaks because of it.

We're strongly considering moving to "one big repo" to help combat this issue
(as well as a few others) for our internal golang repositories. Referencing
"published commits" in 3rd party libraries is an acceptable level of pain.
We're not entirely sold on this yet... just considering it.

------
DAddYE
I'm very happy for this:

"Cross compiling with cgo enabled is now supported. ... Finally, the go
command now supports packages that import Objective-C files (suffixed .m)
through cgo."

Great news!!!!!!!!!!!!!!!!!!!!

~~~
chrissnell
I'm a little confused at what it takes to get this going. I want to use cgo
for a linux/arm target, built on darwin/amd64. Do I need to first build a gcc
toolchain for linux/arm on my Mac?

~~~
4ad
Yes.

------
lcampbell
> Previously, all pointers to incomplete struct types translated to the Go
> type *[0]byte

This makes me really happy. I end up writing a lot of bindings to C libraries
(libjpeg, libpng, etc), some of which use incomplete types to hide the
contents of their internal structs. With this fix I'll finally be able to work
within the constraints of the typesystem and stop hacking around it with casts
to/from unsafe.Pointer.

------
emanuelez
I just noticed this session in the Go track for Google IO... It might be
nothing of course, but I don't remember seeing anything Android related in a
Go session before:
[https://www.google.com/events/io/schedule/session/eeeb1991-0...](https://www.google.com/events/io/schedule/session/eeeb1991-0ce1-e311-b297-00155d5066d7)

------
timewasted
I rather like the new Server.ConnState callback, as well as the various HTTP
timeouts. Yay for simple but useful quality of life improvements!

------
yelnatz
Very excited about Sync.pool and the contiguous stack.

------
frik

      warning: GOPATH set to GOROOT (T:\Tools\Go) has no effect
      go build runtime: windows/386 must be bootstrapped using 
      make.bat
    

So, if you installed Go in a different directory, ignore the Windows
environment vars "PATH" entry and just execute the "make.bat" in the "Go\src\"
directory - the first time.

------
gejjaxxita
As a scientific programmer I find it a shame that they have decided not to go
with operator overloading. The rationale from the FAQ is that it "seems more a
convenience than an absolute requirement". In the case of scientific software
though it usually is a requirement.

~~~
PopsiclePete
I'm honestly glad that Go, unlike C++, does not have features that are useful
_only_ for a small subset of programmers. The only 2 cases I've seen where
operator overloading is useful are:

1\. String concatenation (Go has it) 2\. Matrix/vector operations

That's it. Any other use case for operator overloading is dubious at best. It
sucks for scientific programmers, but Go is a general purpose language, not a
Scientific Programming language.

Complicating parsers, the grammar, readability, all those things, just to
please your sub-group -> no thanks.

~~~
gejjaxxita
I don't disagree with you. I'm not suggesting that Go designers made the wrong
decision with the goals they had. I am jealous that it's less useful to me
though.

~~~
mattyw
forgive my ignorance, why is operator overloading particularly useful in
scientific computing?

~~~
NateDad
Because it lets your math code look more like math and less like code.

    
    
        v := Vector{}
        v2 := Vector{}
    

to add the two vectors, currently you have to do something like

    
    
        result := v.Add(v2)
    

rather than the nicer

    
    
        result := v + v2
    

In the small scale, it doesn't seem like a big deal. In a large and
complicated scientific program, it can make the code a lot harder to read.

Note: I think it is good that Go does not have operator overloading, though I
think it's a shame that means it's not as good for scientific & math
programming.

------
zkirill
Congratulations and excellent work!!!

------
ohwp
Maybe the time has come for Google to use Go for Android. I think it will give
Go a nice boost.

~~~
dcre
Swift's high-level syntax will probably open up iOS development to many people
who otherwise would have seen Objective-C's square brackets and run away.

I like Go a lot, but Google switching to it for Android would probably have
the opposite effect. Many people learn Java in school. Almost no one learns
Go.

~~~
bsg75
People don't learn Objective-C in school, but it has not slowed down adoption
of the language for the iOS platform. If the platform is popular, and a
language supports it well, programmers will learn.

------
natural219
...But does it have generics?

~~~
duaneb
I think it's pretty clear by now Go is not aligning itself with type
parameters. If you need generics, don't use Go. Most programs probably don't
need generics.

~~~
Touche
Most programs do list manipulation and list manipulation in Go is a pain.
Generics are one solution for that.

~~~
nonuby
I agree generic would be a serious win for Golang. However in the meantime we
have this workaround/hack which alleviates some of the pain
[http://clipperhouse.github.io/gen/](http://clipperhouse.github.io/gen/)

~~~
mwsherman
Appreciate the mention! Also gen is getting more, um, generic with the notion
of custom ‘typewriters’, out on this branch:
[https://github.com/clipperhouse/gen/tree/3.0](https://github.com/clipperhouse/gen/tree/3.0)

------
cnbuff410
Congrats, guys! Thanks for the great effort.

