Your metaphor certainly resonates with me, but there are two mixed concepts here:
1) The 'zen' axis of language syntactic joy.
2) The 'practicality' axis which is a kind of mix of size of the standard library, availability of 3rd party libraries that do Really Cool Useful Stuff and the speed of the resulting binary.
Your toolkit isn't really about the zen axis. It's about the practicality axis, and that's where java with its epic standard library, and c++ with its insanely huge number of 3rd party libraries are the workshop, and go is the empty room with a desk.
I mean, the go standard library is amazing (http://golang.org/pkg/) but its missing some of the features you might want if you're say, trying to build a desktop application on windows...and there just isn't (yet) the 3rd party support for it.
Professional work is, as you say, strongly tied to the practicality axis.
Yet, its worth noting that there are certainly domains that even now go is a better and more practical target for applications than C++ or java, with a comparable runtime speed. Specifically, I'd suggest, cross platform system level tools and web applications.
It doesn't really surprise me that most C++ programmers haven't jumped to go; I'd wager most C++ programmers work on applications that don't cross into these domains.
IMHO, its not fair to compare Go libraries (at this stage) with the more mature implementation of libraries in C++ and Java. That will come with adoption, but even at this early stage, the set of libraries that come with go offer a lot of power.
Agreed Java came out of the gates with a good (??) desktop programming library. Google Go's library on the other hand is very web oriented with the building blocks of http, templating, json all woven in - maybe its a better approach to take, seeing how desktop programming is fast disintegrating into a proprietary, incompatible mess with bottle windows (metro) and apple (ios) locking up their environments.
I agree heartily with the zen metaphor, when programming in Go, I find the language recedes to the background and allows me to focus on the task at hand. That's the hallmark of a great language design.
The very very very fast compilation times (you have to experience this to believe it), helps a lot. Gives it the fast turnaround of a scripting language without any loss of power/ expressiveness.
The point I was making is that right now go has a poorer set of 3rd party libraries than, for example java or c++, and that means that as a practical target it's not as attractive for people writing particular types of software.
It's patently absurd to argue that because go > C++ on the 'Zen' scale, that it's somehow also > C++ on the 'practicality' scale. These two axes are not totally independent (arguably say, the verbosity of java for example, decreases its value on the practicality scale) but they're weakly related.
Having a toolkit like QT makes C++ a vastly superior choice to go for a desktop application, despite the fact that C++ lies somewhere on the dark depths of hell on the 'Zen' scale.
What I was saying, and agreeing with the OP on, is: Pick your tool for your problem.
In some cases, that's Go. In some its C++. In some it might be java; but not having all those tools lying around that people can pickup to use is a major failing for go.
...and sure, that'll change eventually I'm sure; but it's an entirely valid complaint right now
>IMHO, its not fair to compare Go libraries (at this stage) with the more mature implementation of libraries in C++ and Java.
It's not about being 'fair', it's about being practical. If a project has a need for X, a programmer cannot wait until X feature of lib is added to a language to start his work.
> I mean, the go standard library is amazing (http://golang.org/pkg/) but its missing some of the features you might want if you're say, trying to build a desktop application on windows...and there just isn't (yet) the 3rd party support for it.
1) The 'zen' axis of language syntactic joy.
2) The 'practicality' axis which is a kind of mix of size of the standard library, availability of 3rd party libraries that do Really Cool Useful Stuff and the speed of the resulting binary.
Your toolkit isn't really about the zen axis. It's about the practicality axis, and that's where java with its epic standard library, and c++ with its insanely huge number of 3rd party libraries are the workshop, and go is the empty room with a desk.
I mean, the go standard library is amazing (http://golang.org/pkg/) but its missing some of the features you might want if you're say, trying to build a desktop application on windows...and there just isn't (yet) the 3rd party support for it.
Professional work is, as you say, strongly tied to the practicality axis.
Yet, its worth noting that there are certainly domains that even now go is a better and more practical target for applications than C++ or java, with a comparable runtime speed. Specifically, I'd suggest, cross platform system level tools and web applications.
It doesn't really surprise me that most C++ programmers haven't jumped to go; I'd wager most C++ programmers work on applications that don't cross into these domains.