The Go Programming Language Specification

Version of June 29, 2022

The Go Spec gets updated periodically. As of this writing, the latest version was updated June 29, 2022. However, Go 1.20 is scheduled for release in February, and will include some language changes.

Throughout this series, I will be referencing the then-current, released version of the spec. And to reduce confusion, I’ll be sure to include the release date of the spec at the bottom of each email. That does mean that sometime in February, I’ll begin going through a newer version of the spec. I’ll likely try to retroactively address any topics that have changed at that point, or any other point in the future when the spec changes.

So with that out of the way, let’s look at the first section of the Go Spec, the Introduction

Introduction

This is the reference manual for the Go programming language. The pre-Go1.18 version, without generics, can be found here. For more information and other documents, see golang.org.

Go is a general-purpose language designed with systems programming in mind. It is strongly typed and garbage-collected and has explicit support for concurrent programming. Programs are constructed from packages, whose properties allow efficient management of dependencies.

The syntax is compact and simple to parse, allowing for easy analysis by automatic tools such as integrated development environments.

Most of this introduction should be pretty self-explanatory, but I think one aspect in particular deserves some discussion, at that is the topic of “systems programming”, and what it does, and does not, mean in the context of Go.

Go was originally designed at Google in 2007. As such, the creators had a specific set of use cases in mind, which can be broadly classified as “systems programming”. Although “Systems programming” often includes the writing of operating systems, to my knowledge, there are no operating systems, in the traditional sense, written in Go. Certainly no major ones. However, Go does serve a niche just above the operating system layer, if you will, perhaps even bluring the operating system and application layer, with tools like Docker, which is famously written in Go.

Go’s first-class concurrency primitives (namely, channels and goroutines, which of course we’ll talk about in due time) make it very powerful for a broad range of “systems programming” tasks, where efficient and easy-to-debug multitasking is important.

Some have taken this “systems programming” focus to mean that Go is unsuitable for “non-systems” tasks. While some of this criticism may be justified, there’s often not a very clear distinction between “systems programming” and “non-systems programming.”

While Go probably isn’t ideal for games (though some definitely exist) or mobile apps (again, exceptions exist), it’s harder to make the case that Go isn’t a good fit for web or microservices, even though these may not be traditionally considered “systems programming.” In fact, in my professional experience, I’ve mostly used Go in these ways.

The bottom line, in my opinion, is to recognize that Go was designed with systems programming in mind, but as it is a Turing complete language, we should not be the least bit surprised that it has strengths that extend beyond this specific focus. And it is likely to continue to gain support in a broader array of areas. So don’t be put off if you’re thinking of using Go for something that isn’t “systems” related.

The Go Programming Language Specification, Version of June 29, 2022