Google's Go language project, which runs at C-like speeds but allows for the dynamic development usually reserved for languages like Python, is about to enter its 1.3 revision, with a first beta soon to be made available.
Based on the currently published documentation, most of the changes in Go 1.3 don't involve introducing new features to the language, but rather addressing many of the issues and complaints that have popped up during its few years in the wild. A few of the new features position Go as a one-stop-shop language for all things Google, including the Native Client architecture that Google has been proposing as an alternative to the "JavaScript everywhere" philosophy.
The first set of major improvements to Go 1.3 involve the linker and compiler, both significantly reworked to allow programs -- especially larger ones -- to compile more quickly. Google has touted Go as a way to build large distributed applications, so having less of a bottleneck on the compiler side is a boon.
In the same vein, performance for binaries created by the Go compiler has also been improved, with faster and more efficient garbage collection and a reworked regular-expression handler. Features like a smaller default stack size and less memory use per routine mean applications have a smaller memory footprint.
But the picture get more interesting with the new platform support features in Go 1.3. Aside from dropping support for Windows 2000 entirely, experimental support has been added for four new platforms: Oracle Solaris, Bell Labs's experimental OS Plan 9 (the source of many cutting-edge operating system ideas over the past decade), FreeBSD, and -- most significant -- Google's NaCl (Native Client).
NaCl was created by Google to allow C/C++ code (and now, it seems, Go) to run in a secure and efficient way across different machine types, architectures, and platforms. Controversy has swirled around NaCl since its inception, and proponents of JavaScript as a universal platform have pooh-poohed the concept as being redundant.
Also, most of Go's uptake has been with designers of back-end services and APIs, rather than the end-user software that would be deployed in NaCl. (Google App Engine supports Go as one of its small clutch of languages.) To that end, adding NaCl target support seems to be a hedge, a way to generate more of a developer base and an application target for items written in Go. Support for NaCl in Go is also currently limited to Intel architectures, and manual heavy lifting will be needed to get it running for Go users.
Google devised Go as a way to address problems experienced by programmers and Google alike. One of the biggest was concurrency: How do you write software that runs in parallel across multiple nodes without it becoming unmanageable on either the code or the machine side? Go's solution was to bake a concurrency methodology, called channels, directly into the language, thus avoiding the need to use threading or third-party message queuing systems. Testing distributed systems written in Go without actually building one from scratch is a tougher problem, although some Go projects (such as Stadis) can help on that front.
A language with native solutions for those problems has a lot of potential appeal, but the larger question is whether such problems can be solved elegantly in an existing language that already has a broad base of users enthusiastic to engage with them. Go currently ranks 15th or so in the list of languages used by GitHub projects, and while it's showing a steady increase in the number of projects that use it, its sheer newness and flux may continue to work against it until its niche among developers -- maybe even with Google itself -- becomes fully defined.
This story, "Go 1.3's first beta promises a sleeker, faster language," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.