C and C++ are so widely known and broadly supported that it borders on heresy to suggest that they may not now and forever be the best languages for high-performance systems programming. The Go language, originally designed by Robert Griesemer, Rob Pike and Ken Thompson, dares speak that heresy. The three chief distinguishing characteristics of Go are fast compilation, garbage-collected memory, and concurrency via Communicating Sequential Processes.

Of those, “fast compilation” seems to be the one that causes the most surprise. If you’ve never been given a “speed up the build” assignment on an industrial-sized C/C++ codebase, know that you have avoided a nightmare corner of the software world. (You really find out who your friends are after you commit a “fix” that takes the build from overnight to “overnight and into the next workday.”)

Walter Bright, designer of the D language, has said that it takes seven passes just to tokenize C++ text! In the same post, he lists non-parallelizable dependencies, preprocessor semantics, overuse of “#include,” and the lack of context-independence as other insuperable obstacles. Bright implemented Zortech C++, the first native-code compiler for DOS, more than 20 years ago, and if he’s never figured out how to reduce the number of text passes below three, I’m ready to bet that no one else has, either.

Of course, it’s doubtful that anyone outside of Google looking at a major infrastructure system with hundreds of compilation units is thinking, “Oh, hey, why don’t we try it with a new language and see how that goes?” While it’s sensible to explore Go with a pilot project or two, it would be foolish to fully commit to a language with such a short track record and so few developers.

Garbage-collected memory is not a surprising language feature in mainstream development, but relying on it at the systems level is one of Go’s bolder design decisions. The current garbage collector in Go is stop-the-world, non-generational and non-compacting, so it’s not a state-of-the-art leap forward. On the face of it, there is no easy way to use manual memory management with Go short of linking in a C-based module, so I could definitely see scenarios where that would seem to disqualify Go from consideration.

The concurrency model of Go seems solid, derived from Hoare’s “Communicating Sequential Processes,” which, as you’d guess, is a message-passing model. The runtime is charged with handling the details of mapping your code’s very large number of conceptually concurrent entities to the relatively few and heavyweight OS-level threads; that removes an entire category of effort. However, although one is encouraged to use channels and “goroutines” (coroutines), Go has clearly left “enough rope to hang yourself with” when it comes to deadlocks and consistency pitfalls. This seems a little at odds with the relatively aggressive “take it or leave it” garbage-collected memory management. Do I think Go’s concurrency model makes manycore development easier? Definitely. Do I think it makes it as easy as, say, Erlang? I don’t think so.

Educational resources center on the Go homepage at www.golang.org, but there are also at least two books on the language in print. David Chisnall’s “The Go Programming Language Phrasebook” appears to be a pocket reference, but it is much more. It’s actually an excellent self-paced tutorial on idiomatic Go programming, and its introductory chapter is the best account of the language’s justification and genesis that I’ve read. I highly recommend it as your first book on the language.

Those who have made more of a commitment to the language may forego Chisnall’s book for Mark Summerfield’s “Programming in Go: Creating Applications for the 21st Century.” This much heftier text is also well written and goes into significantly more depth on the standard libraries, and it presents more complex examples.

Version 1.0 of the language was released in late March, and binary distributions are available for Linux, FreeBSD, OS X and Windows. The language is open source and BSD-licensed.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.