Before we start: What is the Go Spec?

January 2, 2023

It’s a new year. Time for a new daily email list, and a new series!

My plan is to spend the next while (a few months, most likely) each day expounding on a small section of the Go Programming Language Specification, or Go Spec for short.

But what is a programming language specification, and why should you care about it? In short, it “is a documentation artifact that defines a programming language so that users and implementors can agree on what programs in that language mean.”

Not all languages have formal specifications. Wikipedia notes that Perl 5 has no formal specification, and prior to 2014, PHP was unspecified.

But Go is not at all unique in that it has a formal specification. But the fact that it has a specification, and more to the point, the fact that it has a single specification, and multiple implementations, tends to trip up people from time to time. No doubt I’ll talk about some of this as relevant topics are presented during our tour of the Go Spec.

The Go Spec is a formal explanation of the Go Programming language, and reference manual. It’s not intended to be used as a tutorial. However, it is fairly accessible. That is to say, you don’t need a PhD in Computer Science or other advanced training to make sense of it.

There are still some parts that are fairly dense in technical details, though, and that’s where I hope this series will help.

I have two primary goals in writing this series:

  1. I want to make the Go Spec accessible to you. Whether you’re new to all programming, or you have decades under your belt, my goal is to show you that the Go Spec doesn’t need to be intimidating, and that you can use it as a regular part of your Go programming journey.
  2. I want to use the Go Spec as a guide through the langauge. There are many ways to organize a course, book, or other learning journey through a language. I’ve yet to see one that does this by going through a language formal spec (although it wouldn’t surprise me to discover that some such examples do exist).

This is an experiment. I’ve never tried explaining the Go Spec (or any other) on a point-by-point basis. In fact, I’ve never even read the entire Go Spec (though I certainly have read many portions). So I’ll be learning as we go along.

I want your feedback! If anything I say is unclear, confusing, or wrong, please let me know!

And if you find anything in this series to be helpful, I’d love if you’d share it with your colleagues, with your team, or on your favorite social media hangout.


Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content


Introduction

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.


Don't panic!

Later today, at 15:00 UTC, I’ll be joining Denis Čahuk and Adrian Stanek on their regular Livestream, Our Tech Journey, to talk about TDD, Go, and do some live coding. Join us! The second in our list of terminating statements is… panic! Terminating statements … A call to the built-in function panic. Don’t panic. Don’t panic is such ubiquitous Go advice that it’s one of the famous Go proverbs. So why do we have a built-in panic function if we’re not supposed to use it?


Terminating statements

Terminating statements A terminating statement interrupts the regular flow of control in a block. The following statements are terminating: A “return” or “goto” statement. The return statement should be familiar to virtually everyone. And the fact that it interrupts the regular flow of control should be no surprise: func foo() { fmt.Println("Hello there") return fmt.Println("You'll never see me!") } In this above example, the second fmt.Println is never called for fairly obvious reasons: The preceeding return statement interrupts the flow, and returns control control flow back to whatever code called foo() in the first place.