I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features):
On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing all artifice, leaving only pure creation.
On the other side, take a look at your average real workshop: a mechanic's garage, a woodshop, or an operating theatre. They are filled with tools. Mastery is knowing a hundred different implements, each carefully designed for one or a few uses. Mastery means having tamed a thousand tools and knowing which one is the perfect one to apply to the situation at hand.
Programming languages live on a continuum between these points. Over in Zen land, you've got Scheme and Go, maybe Smalltalk and JavaScript. Over in everything-but-the-kitchen-sink territory, you've got Java, C#, Common Lisp, and C++.
The first image certainly seems cooler: you as code ninja wielding vi and lambdas with deadly precision. It's the aesthetic of the artist and intellectual. The second image is blue collar, the tradesman, the kid who took shop class for four years, the vocational school graduate.
If we accept the second image, that says something deep and maybe unpleasant about how we look at our work. But, honestly, I think the reality is that quality professional work often looks like the second picture. Every time I go to Home Depot and get some random tool that only does one thing (basin wrench, water heater element remover, you name it), it takes a job that would be hours of frustration and turns it into child's play, and the quality of the work is better.
Simplicity is a virtue worth striving for, but I think it's also valid to want tools perfectly suited for certain tasks. The real art is balancing the two.
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.
Using a hundred different pliars and wrenches doesn't make your car any harder to fix down the road. Using a hundred different types of screw heads does.
I think you make a good point, but I would argue that Go finds that balance. Sure, Go's design is more ideologically motivated than, say, C++, but it is not ideological to a fault. (And I think Rob hints at this in the article.)
I think Go hews to the minimal side, but I agree that it definitely aims to be practical and full-featured. The language itself is small, but not painfully tiny (unlike, say, Scheme), and the standard library is quite nice from what I've seen.
The main difference between your "zen" languages and your "kitchen-sink" languages seems to be whether they've standardized their basic libraries, or whether everybody brings their own. I don't think it's controversial to say that virtually all programmers use libraries (both built-in and third-party).
Javascript and Scheme programmers don't build everything from first principles, and C# and Lisp programmers don't need to study for years more just to figure out which wrench to use. The working-set of programmers in either kind of language is comparable in size and functionality.
I think simplicity is a virtue you should strive for in your designs. How complex, messy, dirty your tools are which you use to create those simple designs doesn't really matter.
In the end you don't see the 2 dozen different kinds of tools a master craftsman used to create the beautiful desk. Nothing dirty and blue collar about that.
On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing all artifice, leaving only pure creation.
On the other side, take a look at your average real workshop: a mechanic's garage, a woodshop, or an operating theatre. They are filled with tools. Mastery is knowing a hundred different implements, each carefully designed for one or a few uses. Mastery means having tamed a thousand tools and knowing which one is the perfect one to apply to the situation at hand.
Programming languages live on a continuum between these points. Over in Zen land, you've got Scheme and Go, maybe Smalltalk and JavaScript. Over in everything-but-the-kitchen-sink territory, you've got Java, C#, Common Lisp, and C++.
The first image certainly seems cooler: you as code ninja wielding vi and lambdas with deadly precision. It's the aesthetic of the artist and intellectual. The second image is blue collar, the tradesman, the kid who took shop class for four years, the vocational school graduate.
If we accept the second image, that says something deep and maybe unpleasant about how we look at our work. But, honestly, I think the reality is that quality professional work often looks like the second picture. Every time I go to Home Depot and get some random tool that only does one thing (basin wrench, water heater element remover, you name it), it takes a job that would be hours of frustration and turns it into child's play, and the quality of the work is better.
Simplicity is a virtue worth striving for, but I think it's also valid to want tools perfectly suited for certain tasks. The real art is balancing the two.