Yesterday, Google announced a new open-source programming language called Go, a systems implementation language that is a blend of Python and C++.
Thus far, the reaction from developers has been mixed. Most geeks are not so much agog, as perplexed: Why a new language? Why now?
However, there are a few, those with the strong strain of the curiosity gene, who’ve dived into the docs and downloaded the code, who hold a different view. They see the rationale behind Google’s move, but are mostly too busy to vent their views in the blogosphere.
They see a significant advance in language design, one that adroitly addresses a complex mix of requirements and tradeoffs, in order to reach the objective of a high-performance high-productivity development tool for concurrent systems programming. I have dipped into the system and do see the logic. At the same time, I think Go faces a huge adoption challenge. Any language, now matter how well-crafted, faces huge odds.
Before making pronouncements as to future outcomes, it needs to be made clear that this is an experimental language at its earliest stage of development. It is the result of a small project that began less than two years ago. Go does not represent a “long march” strategic initiative for Google (in the way that Google Wave does). Failure of this language won’t have much negative impact for Google.
Anyone introducing a new language must face a vast number of competitors for developer mindshare: niche languages that percolate under the surface of the mainstream, a mainstream that includes not just Java and C# but Perl, Python, PHP and Ruby. These are all well-established, visible alternatives, compared to what lies under the mainstream: languages like Squeak, Haskell, ML, Erlang, Lua, Alef, Limbo, Scratch, and, going further back, Dylan, Telescript, Liana, Oberon, Bliss,Modula, Kaleida, and many others. Some of these niche languages have a loyal following, but won’t become mainstream any more than Lisp, APL, or Smalltalk will grow beyond their present tiny communities.
So if it were anyone else, it would be easy to forecast the eventual outcome of Go as an interesting footnote in the history of programming.
Google is not the ivory tower of Bell Labs. Instead, Google is a vast, real-world, proving ground for the most intensive software development projects. Google has intensive needs at two ends of the spectrum:
- the requirement for high agility and programmer productivity, of the kind that results from a modern dynamic language
- the requirement for high-performance and scalability, including the ability to exploit multi-core architectures and concurrent processing
Historically, a common approach to software development at Google is to create a prototype in a high-productivity language like Python, one where a developer can iterate rapidly through the compile-run-debug cycle until the appropriate mix of functions and features is arrived at. Once the design is considered complete, the development team then undertakes the laborious step of re-casting their design in a high-performance, highly scalable system: in most cases C++ (in some cases, as in Google Wave, it is Java).
The grand experiment that Pike and colleagues have embarked upon is to see whether these two very divergent needs can be satisfied by a carefully designed and well crafted language.
The syntax has been designed for rapid compilation and linking. In a TechTalk at Google a couple of weeks ago, Pike demonstrated compiling and linking a math library of perhaps a couple of thousand lines of code in 200 milliseconds, and recompiling the entire Go system (about 120,000 lines of code) in about 8 seconds — all on a laptop with single-core. This is an order-of-magnitude faster than conventional systems.
The Go language is larger than C, but smaller than C++, and feels like a blend of Python, C, with echoes of Squeak, Alef and Limbo (earlier languages that Pike has been involved with).
This appears to be entirely a Google project. It is driven by the internal motors and motivation of Pike and colleagues, as well as by Google’s top-level requirement for agility-plus-performance. The BSD-style license is intended to foster diffusion of this infrastructure-level software, but I think Google cares more about exploiting this tool internally — as opposed to projecting it externally, as some kind of “lock-in” weapon in a protracted platform war.
If Google views this as something to market and project onto the outside world, I think they will struggle to get adoption — primarily because of the mountains of legacy code that are out there. Many Web developers embarking on a project hold their nose and program in PHP because of the large corpus of open-source components and solutions that are available in that language compared to others. Likewise those writing back-end systems in Java, C# or C++ think: Why reinvent the wheel when you can download it from SourceForge?
Even within Google’s own internal context, the Go language will have a challenge getting incorporated into the fabric of company software assets.
I think it will be 3 years before Go has a big impact within Google (assuming it does not wither on the vine). And there will likely be another 3 years after that, before any significant impact in the enterprise sector. Adoption will be driven from by third-parties building solutions, and by enterprises adopting Google App Engine (assuming GAE gets updated to support Go).
In the meantime, the Go source code makes for interesting reading on a cold winter night. It harkens back to the day when programmers read entire programs, similar to young writers learning their craft by reading long novels written by masters. The work of computer-science masters (Thompson, Kernighan, Ritchie, Dijstra, Knuth, Wirth, and so on) constitutes genuine literature, in contrast to more recent work which may be functional but is not so readable. I still have my printout of V7 of the Unix operating system, on the shelf next to A Portrait of the Artist As A Young Man. The design of Go is intended to encourage readability, unlike modern programs that result from developers using Intellisense and auto-completion to churn out endless streams of verbose text that may be syntactically correct but hard to savor.
What are your thoughts on language? In the dead of night, are all cats gray, and all languages nothing more than Turing-machine equivalents?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.