Google exec: Java is too complicated, let's start over

Is Google fracturing Java, or saving it? I asked those questions, somewhat in jest, a couple of weeks ago. I think the truth is something closer to this: Google is an enormous company that cheerfully allows various business units to chart their own paths, using available tools. For some, Java, conveniently open sourced, is one of those tools. Others are attempting to move beyond it, or even compete with it. Into this category follows the group that's developing a new language, called Go. Java, it seems, is part of the problem that Go is trying to solve, according to Google distinguished engineer Rob Pike. This is Pike talking about what he calls "industrial languages," like Java and C++:

I think these languages are too hard to use, too subtle, too intricate. They're far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time ... They're oversold, and used far too broadly.

Developer World's Joab Jackson talks about Pike's pitch to the developers at the O'Reilly Open Source Conference on this theme -- and the history of such complaints, and the fact that virtually every new programming language and construct for the past generation has been specifically sold as solving the problem of complexity. (To choose only the most obvious example within the Java ecosystem, the Spring Framework was originally developed to be like Java EE, but not insanely complicated.) The increases in "subtlety, intricacy, and verbosity" that Pike notes as being part of the trajectory of programming languages are, to my mind, related to the "used far too broadly" problem. Developers come to love a language, and want to use it to solve new problems, and then want features that the solutions to those problems require.

Still, you can see how the bewildering complexity of modern industrial languages could offend the folks at Google, who often enjoy a minimalist aesthetic. One eyebrow-raising fact from Jackson's article: Google's Gmail service is written entirely in JavaScript -- and entirely "by hand," which I assume means without intervention from an IDE. One of the facts of life development that might depress anyone who remembers the joy of writing their first primitive BASIC program is that virtually every application in practical use today -- including, I'm guessing, almost everything written in Java -- is built with a tooling layer between the developer and the code.

I'm sure that the people behind Go believe that their language will avoid all these problems that have arisen in every other language in the history of computing, but I for one will not hold my breath! Once a language becomes a "legacy language," like Java, it accumulates all kinds of cruft, and ends up being the subject of articles like this, about how to wade through the morass. If Go is lucky enough to be take root in practical applications, my guess is there'll be articles like that written about it in a decade or so.