Harder than scripting, but easier than programming in C

Programming Snapshot – Golang

© Lead Image © alphaspirit, 123RF.com

© Lead Image © alphaspirit, 123RF.com

Article from Issue 250/2021

Released back in 2012, Go flew under the radar for a long time until showcase projects such as Docker pushed its popularity. Today, Go has become the language of choice of many system programmers.

In 2012, Unix and C veterans Robert Griesemer, Rob Pike, and Ken Thompson released the system-oriented programming language Go under the aegis of Google. For a long time it eked out a niche existence, before eventually becoming the industry standard for system-oriented programming. Today, observers of the Unix scene are rubbing their eyes in disbelief over the number of tools developed in Go.

To name a programming language after an everyday word such as Go seems like a pretty crazy idea from the viewpoint of a search engine operator. After all, search engines actually remove filler words such as "go" from incoming queries. So, when looking for Go programming tips, the recommendation is to search for "Golang" instead, which has also become the accepted name for the language in the community.

Quickly Installed

If you want to try Go, the easiest approach is to grab a package for your favorite distro. On Ubuntu, for example, type:

sudo apt install golang

After the install, go build gives you a super-fast Go compiler; gofmt a pretty printer; go doc a renderer for manual pages, an extensive core library, and much more.

Go offers a mature development framework, a huge standard library for handling typical programming tasks, support for automatic testing, and a lively community that keeps uploading new libraries to GitHub, from which you can easily include them in your own applications via simple references in your own code.

In the following exploration, I'm going to present only a limited number of useful language features; many may sound familiar, as you might have heard of them in typical "language wars" in the vein of endless discussions such as "Emacs vs. vi". If you want to learn more, I recommend Go's online interactive tutorial [1] or the excellent original book written by one of the Go makers [2].


The Internet community has wasted a good deal of energy over the years infinitely discussing the right number of indentations or spaces between keywords or even the "right" editor.

Following Python's strict example to some extent, the Go community prefers a very specific code format. The compiler doesn't grumble if someone now uses four or eight spaces for indentation instead of tabs, but the community insists on principle that any code is run through the gofmt prettyfier first before it appears anywhere online in a repository such as GitHub. The formatter rigorously sets tabs for indentation and removes spaces between round brackets and text, but puts spaces around punctuation such as + or = for easier reading. There is no arguing with this; it is just the way things are done.

The situation is similar for CamelCase within variables and functions: geoSearch() is in; geo_search() is out. By the way, it also matters whether you start a variable with upper or lowercase. In a structure or package, Go exports uppercase variables outside the current context, and lowercase variables remain private.

Result or Error?

One hot topic in programming languages is the pros and cons of exceptions (Java, Python) versus returned error codes. Go sees itself in the tradition of the classics like C (which is understandable given Go's list of authors) and evaluates return values with each function call – but with a twist. Since Go functions can return several values, an error code usually comes back along with a result, like with the ReadFile() function from the Go os standard library, for example (see Listing 1 [3]).

Listing 1


package main
import (
func main() {
  data, err := os.ReadFile("/tmp/dat")
  if err != nil {

The first return value, data, contains the data found inside the specified file, as an array of the type []byte after a successful read operation. However, if something goes wrong, an error is returned as the second value in the err variable. The main program code checks this result as instructed with err != nil. This returns a true value for the if condition in case of an error because, in case of success, err is set to nil.

By the way, in case of an error, you should not use the other return value (data). Usually, it is set to its so-called null value in Go anyway, which variables assume after they are declared but not yet initialized. In the example of an array of type []byte, this is an empty array.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Rat Rac

    If program parts running in parallel keep interfering with each other, you may have a race condition. Mike Schilli shows how to instruct the Go compiler to detect these conditions and how to avoid them in the first place.

  • Simultaneous Runners

    In the Go language, program parts that run simultaneously synchronize and communicate natively via channels. Mike Schilli whips up a parallel web fetcher to demonstrate the concept.

  • Fighting Chaos

    When functions generate legions of goroutines to do subtasks, the main program needs to keep track and retain control of ongoing activity. To do this, Mike Schilli recommends using a Context construct.

  • Motion Sensor

    Inotify lets applications subscribe to change notifications in the filesystem. Mike Schilli uses the cross-platform fsnotify library to instruct a Go program to detect what's happening.

  • Progress by Installments

    Desktop applications, websites, and even command-line tools routinely display progress bars to keep impatient users patient during time-consuming actions. Mike Schilli shows several programming approaches for handwritten tools.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More