"Part of the problem, he says, is that language designers don’t always have practical objectives. “There’s a tendency in academics of trying to solve a problem when no one actually ever had that problem,” said Rabkin, who recently received his computer science PhD at Berkeley and is now at Princeton working on a post-doc. "
I was at Google when Go was birthing (not part of the project or team, just co-employed :-)) and asked the team "What problem does this solve?" I asked because I had been part of the original Java team at Sun. One of the things I had learned at Sun from James Gosling, who had previously done a language for window systems, NeWS, was that the only reason to have a new language is that it solved a problem you could not easily solve with the existing languages.
If you look at all of the durable languages, they share this heritage. BASIC solved the problem of what you had to learn before you could actually program problem. FORTRAN, solved the problem of converting Formulae into computation, which was later made into high art in Mathematica. COBOL which could express business process in code, and of course C which was a logical follow on to BLIS which was the minimal wrapping over assembly language so you could implement large systems and still read the code later and know what they were doing.
I didn't get any sort of coherent answer from the Go team at the time. Which for me was an indication they were a solution in search of a problem, and thus not likely to be much more than a niche language. But to be completely fair I've seen good languages like Rexx go nowhere even though they solved a huge problem (automating the integration of different programs).
A co-worker at Google suggested that we should start holding meetings in High Elvish, their reasoning was that it would keep people out of meetings who were at least motivated enough to learn elvish, and it sounded better when you swore. But applying a language change to solve a structural problem was never going to fly.