I've been using Go for 2 years now. It's been a lot of fun. It certainly brought fun back into programming for me. Very happy to see the 1.0 release hitting the public. Congratulations to the Go team and contributors for a job very well done!
Good question. And one I can't easily answer to be honest. In most respects I suppose this is very much a subjective matter.
For me it's the language's simplicity. There are no hidden surprises in the spec. It's short, clean and easy to memorize. The syntax is clear and (for the most part) un-intrusive. Some of it's idioms really force you to think about what you have learned in other languages. And then either forget any of that ever happened, or at the very least become a critical thinker about the usefulness of these things. For example: the standard inheritance based OOP model.
Go simply allows me to 'get shit done' fast and without having to jump through hoops. It's very much like a breath of fresh air in what was quickly becoming a stale and obnoxious development environment (for me at least).
Edit: I would add that I do not particularly like evangelising about anything; that includes Go. It is beautiful for what it is. but by no means should it be considered a silver bullet. If your current tool chain(s) and language(s) work for you, by all means continue to use them. Go has its strengths and its weaknesses that should always be considered at the same time.
I don't like to spend time on irrelevant things like "why the binary does not link", "in which shared library this undefined symbol is located" or "how to parse XML", or even plain "why it does not work".
With Go I _usually_ have a predictable process of writing a program, when simple things are simple and complex things are reachable. It makes me happy.
Isn't that just because parsing XML in Go is difficult bordering on impossible? Or are you saying there's some other language that forces you to think about XML when you don't want to?
My point was that with Go, I have consistently predictable experience. Its standard library is still not the most powerful across the Zoo, but if it has support of something, I know that I can use it w/o a book "libxml2 for dummies".
It works - easy as pie. No problems building, linking or worrying about dependencies. (it should be noted that this is a common property of hobby projects)
It's fast, which is nice for the small boy (or girl) in all of us. It is gratifying to make software that can run like blazes.
I get the control over memory layout that I really want. By day I am a Java dev, by night I used to hack Erlang. Neither of these allows me to lay out an array of structs contiguously in memory. I did this for a quad-tree implementation and got 2X speed up on read operations. This means that all the stuff I am reading about CPU architecture, cache-lines and latency etc. can be experimented with in an easy to use environment. That's just pure fun and gratification.
Comprehension. In Java I recently wrote a SOAP server (I know, lame) and it took me an hour of XML fiddling before a more informed person told me that we do that with annotations now.
"Which annotations?
These magical ones.
Ah thanks"
That is a server in Java. At the end I was as ignorant as when I began. But I had the annotations and I had a server. This is bullshit. Programming without learning is like eating without tasting anything. In Go I am learning as I code - this is ecstasy. When I am confused I can jump straight into the library source code, ever tried that in a JEE server? It is painful.
Websockets are fun. Go supports websockets in the easiest way I can imagine.
Errors. Explicit errors in Go are just great. Verbose, yes. But, the clarity of this approach surprised me. All the networking code I have written in Java seemed mysterious. I would hack away and end up with a block of code that would fail from 'somewhere' inside. Errors have taught me a great deal about the different ways my networking code can fail. This is possibly my favourite part of Go (which makes me sound a bit boring).
Green threads are great. I'm sure plenty has been said about this. And message passing too. I won't say more about that.
Closures are marvellous. I have to say that I had a lot of reservations about closures in an imperative language. But if you are careful they are as safe as anything else (in that soup of mutable state). And so much fun.
It should be noted that a lot of my complaints about Java can be remedied. I can read a book about the latest JEE annotations (I did start reading one). I could study the Java networking code better and learn about things that way. But the crucial point is that Go allows me to do all of this while I do what I like best. Hacking. I can build systems and learn at the same time.
I too like Go. But I disagree with some of your analysis.
Java annotations aren't magical; at least no more magical than functions/methods. They're part of packages/libraries and should be documented. You can even write your own annotations.
I'm still not convinced that the lack of exceptions is a benefit of Go. The verbosity of error handling is problematic and seems indicative of a need for a better abstraction. And with respect to your issue of Java exceptions -- I don't know what you mean by "somewhere inside". Did you examine the stack trace?
Succinct, powerful, but readable syntax, but without the feelings of guilt associated with spending significant time in a high level language. At least it's that way for me. :)
