[grey-area]

3 very good (if minor) points here - it'd be great if the go team looked at fixing things like this for a go 2. I've heard talk they don't have any ideas of what might be in a go 2, but a few grammar tweaks like these plus pkg dependencies would be a good place to start. There are definitely some rough edges to the language and some decisions which in retrospect they might not have made, but since it's frozen at go 1, there won't be any changes for the foreseeable future. In some ways that's comforting if you're building real apps on the language, so not at all a bad thing.

I'm not even sure if they need a := operator, is the additional complexity and wasted time worth the benefit (compile error on redeclared variables, most of the time)? It feels a chore having to type out := most of the time and, as you point out, confusing where there are several variables assigned at once.

Another area which is unnecessarily complex is allocation: http://golang.org/doc/effective_go.html#allocation_new

You might use:

    func () (t T) {}
    var t T
    t = T{}
    t := &T{}
    t := new(T)
    t := pkg.New()
    t := make([]T,5)

Though the pkg.New() option is really just an optional convention. It all makes sense eventually, but do we really need all of these options? I'd rather have something like:

    t = T{}
    t = &T{}
    t = [5]T

Still, these are pretty minor niggles, which can mostly be overcome with conventions, except perhaps the use of nil everywhere, which is a shame. There's a lot to like, and the emphasis on simplicity (at the cost of features) definitely is a feature of go, even if it does have some rough edges it is significantly simpler than most other languages both to learn and to use.

[xkarga00]

Rob Pike mentioned variable declaration when asked at GopherCon what he wished he hadn't done in Go

http://youtu.be/u-kkf76TDHE?t=16m10s