After five years and change in the wild, Google's Go language -- with version 1.5 set to come out this August -- has gone from being a curiosity to a promising source for fast-moving new projects.
But what kinds of projects are Go best for building, and how is that likely to change as the language evolves through new versions and grows in popularity? Here are the types of applications where Go really shines, where it works well, and where it'll need to up its game.
The really good: Network and Web servers
Network applications live and die by concurrency, and Go's native concurrency features -- goroutines and channels, mainly -- are well suited for such work. Consequently, many Go projects are for networking, distributed functions, or services: APIs, Web servers, minimal frameworks for Web applications, and the rest.
Go programmers like that the items they use most in such projects are either a part of the language, such as goroutines for threadlike behavior, or available in the standard library like Go's http package. This "batteries included" philosophy hearkens back to Python, as do many of Go's best attributes, such as speed of development and deployment.
The also really good: Stand-alone command-line apps or scripts
Due to Go's consistent behavior across platforms, it's easy to put out simple command-line apps that run most anywhere. It's another echo of Go's similarities to Python, and here Go has a few advantages.
For one, the executables created by Go are precisely that: Stand-alone executables, with no external dependencies unless you specify them. With Python, you must have a copy of the interpreter on the target machine or an interpreter of a particular revision of Python (in the case of some Python scripts).
Finally, none of the above comes at the cost of being able to talk to the underlying system. Go programs can talk to external C libraries or make native system calls. Docker, for instance, works this way. It interfaces with low-level Linux functions, cgroups, and namespaces, to work its magic.
The not so good: Desktop or GUI-based apps
Here's where the going gets a little grimmer. Right now, the culture of software around building rich GUIs for Go applications, such as those in desktop applications, is still scattered.
That said, various projects exist -- there are bindings for the GTK and GTK3 frameworks, and another intended to provide platform-native UIs, although the latter relies on C bindings and is not written in pure Go. Windows users can try out walk, and some folks at Google are in the process of building a cross-platform GUI library.
Lacking right now is a sense of any of these being a clear winner or a safe long-term bet. Also, because Go is platform-independent by design, it's unlikely any of these will become a part of the standard package set.
The less good: System-level programming
While Go can talk to native system functions, it's not as good a fit for creating extremely low-level system components, like embedded systems design, kernels, or device drivers. Some of this is a by-product of the language's intentions, since the runtime and the garbage collector for Go applications are dependent on the underlying OS. (Those interested in a cutting-edge language for that kind of work should look into Mozilla's Rust.)
One project currently in the works that partially leverages Go for systems programming is Ethos, an OS intended to serve as a platform for highly secure software. The kernel is written in C, but the userspace applications will be written in Go -- a smart way to render unto C what is C's, and render unto Go what Go's best at right now.