It might just be me, but I found myself asking "why?" on most of the first 12 pages that I skimmed through. I don't really understand why there need to be so many ways to declare a variable or a function. It doesn't make it easier to have several ways to phrase the same thing, I'd rather just learn the one way to do it.
I've never written a Go program so I don't know if it comes up in practice, but it seems like this kind of variability makes it harder to learn and harder to read other people's code (who may not use the same constructs you use). Something I really appreciate about Python is that it's syntactically extremely simple and there are very few surprises.
From the programming I have done, I would say most of the 'repeated' functionality is things you would have done already, just in different ways. In fact, things like making the while loop a for loop is taking away things you don't really 'need'.
It is quite different when compared to python, but it is probably better compared to C, C++ or even Java. C is nearly 40 years old, a lot of the decisions that were made in its creation look silly now (terminating strings with '\0'? yeah, great choice). From what I can see of Go, they try to address many of these aging conventions.
How about something like a C++ strings? C strings are great for memory-constrained platforms, like computers were back in the day, or small embedded computers now. On a modern computer though, it doesn't make sense. The amount of security problems that C strings cause is unbelievable. So using something different to C strings would hopefully reduce the amount of buffer overflow exploits (you would still have unchecked array bounds though, but they would be less accessible without C strings).
Of course, something like C++ strings might need more processing to do basic things, but between the OS latency/overhead, I/O times and human perception, you wouldn't notice any difference at all.
I don't know what you mean about "many ways to declare... a function." Unless you mean the fact that you can elide repeated types ("func foo(a int, b int)" vs "func foo(a, b int)"), which is just simple sugar to stop repeating yourself; or maybe you're referring to the named result parameters. Both of these are conveniences, and I wouldn't really say that they are different "ways" (syntactic constructs) to do something.
Variables in Go can be a bit tricky, but it's really not too difficult. In functions, declaring a variable with "var" requires a type and optionally and initializer. The ":=" construct declares and initializes a new variable whose type is inferred to be that of the righthand expression. Again it's just a convenience so you can stop repeating yourself.
The problem with having three ways of declaring a variable I think is that you either have to ask yourself each time which is the best way to do it or just have a mental order of which one is the most efficient and take the most efficient one that you can. I would just assume that being explicit about the type is the most efficient way. Is it?
If you don't declare a type, it has to be infered from the argument, which happens at compile time, so there's really no loss in performance. If Go would use some kind of union/variant type in those cases, then yes, that would cost you performance. But something like this is rather common in contemporary statically compiled languages, as nobody wants to uselessly repeat himself (cf. Java's "FrobnicationType frobnicatorVariable = new FrobnicatorType(initialValue)").
It's mostly a matter of style and verbosity, the only thing you have to care about is that you can't use the ":=" outside of functions. And as that will give you compilation errors, you'll notice quickly. No different behavior or runtime faults.
> The problem with having three ways of declaring a variable
Three ways? I only count two, and the rule for what to use is very simple: any time the type can be inferred from the initial value, you use := (obviously you can't use := in other cases, so there isn't really any ambiguity).
I've never written a Go program so I don't know if it comes up in practice, but it seems like this kind of variability makes it harder to learn and harder to read other people's code (who may not use the same constructs you use). Something I really appreciate about Python is that it's syntactically extremely simple and there are very few surprises.