What’s the Go language really good for?

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).

Another advantage Go has here is speed. The resulting executables run far faster than vanilla Python, or for that matter most any other dynamically executed language, with the possible exception of JavaScript.

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.

source : What’s the Go language really good for?