The Story Behind “100 Go Mistakes and How to Avoid Them”

Overall Reception and Usefulness

• Many commenters praise the book as “real-world,” practical, and easy to dip into for specific issues.
• Several recommend it strongly, comparing its role in Go to “Effective Java” for Java.
• People highlight that its “mistake”-based format works well for book clubs and mixed-experience groups, sparking discussions and experience-sharing.

Author Experience vs. Expertise

• One thread notes the author initially hadn’t written huge amounts of Go, yet still produced a strong, accurate book.
• Others counter that many programming books by low-experience authors show their weaknesses; this one is seen as an exception.

Technical Gotchas Discussed

• The showcased mistake about goroutines and loop variables (mistake #63) triggers a detailed discussion:
  • Clarification that the core issue is loop variable capture in closures, not goroutines per se.
  • Explanation that Go 1.22 changed loop-variable semantics, making this specific bug largely obsolete, though it used to be a common source of missed/duplicated values.
• Another thread calls out sync.Pool with non-fixed-size objects as a serious, under-documented pitfall and suggests it belongs in any “mistakes” list.
• Some discuss arenas and GC behavior, noting Go’s experimental arenas were tried and then dropped.

Maintaining and Updating Content

• Commenters are impressed that the author tracks which “mistakes” are now outdated and documents this on the companion site, reinforcing a sense of craftsmanship and care.

Publishing, Tooling, and Copyediting

• Multiple anecdotes criticize Manning’s editorial processes: awkward tooling (editing AsciiDoc/DocBook in ways that destroy formatting), odd copyeditor choices, and confusing or perfunctory proposal handling.
• In contrast, O’Reilly’s tooling and Git-based workflows are praised as simple and powerful.
• Some argue that comments directly in source (with version control) are preferable to PDF/Word workflows; others find editing raw markup “archaic.”

Writing Style, Length, and “Padding”

• One reader objects to what feels like padding: taking a short explanation and expanding it heavily with setup and commentary.
• The author responds that:
  • Emphasizing how common a mistake is helps orient readers.
  • Even simple snippets benefit from explicit statements of intent.
  • Marginal explanations don’t increase page count and focus reader attention.
• There’s general agreement that “book padding” exists in the industry, but not all publishers push for it; some editors favor cutting “just-in-case” material.

Language Design and “Room for Mistakes”

• A philosophical side-thread debates whether “a good language should leave no room for mistakes.”
• Replies argue that:
  • Any practical language has pitfalls; the goal is to reduce, not eliminate, them.
  • Go has fewer hazards than C/C++ but still many tradeoffs.
  • Feature gaps (historical lack of generics, no exceptions, no default/named args) are cited as “mistakes” that some avoid by not using Go.