Book Review: 100 Go Mistakes and How to Avoid Them by Teiva Harsanyi

August 9, 2023

Any Go developer, beginner or expert, would do well to read this book. Probably more than once.

Prefer to watch this review?


Publication Details

100 Go Mistakes and How to Avoid Them by Teiva Harsanyi, 384 pages. Published October 4, 2022 by Manning Publications Co.

Audience

This book is for developers with existing knowledge of the Go language. … Ideally, you have already worked on an existing Go project at work or at home.
— “About this Book”, page xiv

Many of the examples in this book will be immediately useful to even Go beginners. There are some, however, that touch on much more advanced topics that will generally be more applicable to experienced developers, aiming to squeeze the last bits of performance out of their code. I’d say there’s something in here for virtually every level of Go developer.

Organization

Ultimately, the book is 100 short sections, each of which describes a Go mistake, followed by an explanation, and how to avoid or mitigate the mistake. These sections are grouped by topic into chapters, and some include a conceptual introduction to the topic. For example, chapters 8, Concurrency: Foundations begins with mistake #55, Mixing up concurrency and parallelism, which spends more than three pages explaining the concepts of parallelism and concurrency, and how they differ. This mistake is conceptual in nature, and doesn’t include code. But the other concurrency mistakes, which do demonstrate code mistakes, build on this concept.

This organizational approach makes the book an easy reference source. You can easily jump to just the section you care about, or read through it and easily refer back to the sections that are relevant at any moment while programming.

The short sections make this an easy book to read in short intervals, such as during the morning commute, or perhaps while on the toilet?

Prose Style

I love the author’s humility.

It’s easy, when talking about mistakes, to take a sort of us vs. them or me vs. you approach. I’m sure you’ve experienced that, if you’ve ever been involved in any sort of code review.

That’s not how this book is written.

The author takes your side, and invites you to join the team of fallible Go developers, on our journey toward improvement.

“To be transparent, I was also a decent source of inspiration regarding mistakes,” the author admits on the very first page of the preface.

And with that, we’re off to the races, learning about Go mistakes, some common, some less common, that most of us have made (or will make) in a non-judgemental way, along with a practical explanation of why the problem is a problem, and how to mitigate it.

For an example, let’s look at chapter 10. This mistake I’ve also covered briefly in my video 10 Things I Hate about Go: Using the default HTTP client:

#81 Using the default HTTP client and server

The http package provides HTTP client and server implementations. However, it’s all too easy for developers to make a common mistake: relying on the default implementations…

So what’s the problem with using the default HTTP client?

First, the default client doesn’t specify any timeouts. This absense of timeouts is not something we want for production-grade systems: it can lead to many issues, such as never-ending requests that could exhaust system resources.

Content

A book of this nature is not a complete guide to Go, but it doesn’t claim to be, so that’s okay. If you’re looking for an introduction to the Go language, this isn’t it. For that, check out my post, What is the Best Book to Learn Go in 2023?

Rather, this book provides a gentle, non-judgemental discussion of a number of mistakes that we all make in Go. And true to the title, it discusses how to avoid them. No real surprises there.

The author categorizes the mistakes into a number of types:

  • Bugs
  • Needless complexity
  • Weaker readability
  • Suboptimal or unidiomatic organization
  • Lack of API convenience
  • Under-optimized code
  • Lack of productivity

Naturally, some of these are more serious than others. Some are even somewhat contentious! But even the contentious mistakes are good to understand, even if you choose to go against the author’s advice.

Let’s consider one potentially contentious mistake, as an example. Mistake #11 is Not using the functional options pattern. If you’re not familiar with this pattern, this blog post by Dave Cheney is a good introduction. But in short, when configuring an object instance, functional options are one way to pass those options that provides a number of advantages over using a config struct, or a long list of arguments to a constructor function, for example. One might be forgiven for thinking that the inclusion of this mistake in the book is an indication that the author thinks it is always a mistake not to use this pattern. However, he doesn’t outright say this, and I think there are definitely times when the functional options pattern is unnecessary. That said, it is a powerful pattern, and it’s one any serious Go developer should be familiar with. Don’t just follow the pattern blindly in all cases.

A few of the mistakes described in this book are not Go-specific. Mistakes #18 and #19, for example, Neglecting integer overflows and Not understanding floating points respectively, are problems common to a great many languages. However, they do often trip up Go developers. One of the most common questions I see on StackOverflow’s [go] tag, is “Why are my float64 values inaccurate?” This is a great question, and the answer surprises many newcomers, even though the answer has nothing to do with Go, per se.

The final chapter of the book, Optimizations, in my view, can mostly be ignored by most developers, except when performance is truly important. As Donald Knuth is commonly quoted: “premature optimization is the root of all evil.” More often than I would like, I have conversations with well-meaning developers about doing doing something “the performant, but hard to read” way, vs the “easy to read, but less performant” way. In almost all cases, the easy to read way should win over performance. In the 0.0001% of cases where raw performance actually matters, this chapter is useful. And even in the other cases, you’ll learn some interesting technical tid-bits about Go, and computer hardware, by reading this chapter.

Accuracy

I did not find any overt factual errors in this book, though there may be some I overlooked.

My only real disagreements with the author would be on emphasis, rather than substance. Some of the mistakes described may not actually be mistakes, depending on context. The functional options pattern described above is one such example.

My strongest disagreement with the material provided is in mistake #12, Project Misorganization, because it recommends using the so-called “Standard Go Project Layout”. The book does, rightly, note that “In 2021, Russ Cox, one of the core Go maintainers, criticized this layout.” Despite the name of the project, and the GitHub organization name “golang-standards”, there is no official standard. So be aware. Further, many (myself included) feel that many of the suggestions it offers are overtly harmful. All that said, I do agree with the author’s ultimate conclusion, that “indecisionis the only wrong decision.”

Physical Charactaristics

Manning always prints attractive books. This is no exception. And the table of contents is very accesssible, making this an ideal reference book.

The book is printed entirely in black & white, and that’s just fine. The small number of diagrams present are perfectly understandable in black & white.

Conclusion

There’s a little bit of something in this book for everyone. I’ve been using Go for close to 10 years, and there were half a dozen mistakes in this book that I had never considered before. One example, #72, Forgetting about sync.Cond. Technically, I suppose I hadn’t forgotten about sync.Cond. Rather, I was never really aware of its existence!

All in all, I think any serious Go developer, beginner or expert, would do well to read this book. Probably more than once. Virtually everyone will learn something. And that’s definitely worth the cover price, as well as the time to read it.


Share this

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

Unsure? Browse the archive .