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).
It's pretty sweet, but I felt weird clicking "Compile" when I wanted to click "Run" (or "Compile+Run" or "Go!"). A minor quibble with an otherwise lovely tutorial.
This line just throws me off and don't wanna make me go at it.
import "fmt"
Why would anyone designing language in this decade would allow cryptic names like this in their "Hello World" code? Besides I still can't see single compelling reason to throw away all my tools and libraries in exchange of this thing. Do people create language just for the hack of it?
Looking at the sheer number of esoteric programming languages (befunge, chef, intercal…), or the huge amount of quasy-Rubys and -Pythons, I'd say yes, people do that. And this doesn't even include DSL's, whether they're integrated in a language or stand-alone…
But I don't think Go qualifies as a sheer 'hack value' language. We're talking about something developed under the auspices of Google here. They're looking for a systems programming language, which really hasn't been the focus of recent years (compared to scripting or VM language implementations). The only real contender here are some functional languagues who've gotten fast enough and have some good compilers, but not everybody wants to go all the way in that direction. Considering that Google does a lot of Java, Python and C++, something more in that family seems wanted, and I think Go qualifies here.
Considering that this is the latest language in the C/Unix family and the pedigree of its designers and implementers (Rob Pike, Russ Cox, Ken Thompson(!)), some idiosyncrasies are too be expected. Unix has always been rather fond of abbreviations (`man creat`), and `fmt` doesn't seem any weirder than `stdio.h` – or `printf`.
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.