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

>I tried to explain how review workflows work in a PR-based setup, and gave concrete suggestions for how we could improve the process. But they didn’t want to try it. That might sound like a small thing, but at that stage, all I wanted was a smooth and efficient collaboration process. The easier it was for me to track changes, the better.

I'm surprised the copy editor was more comfortable using git than using a web-based review tool to leave comments, especially given that she was reviewing a Go book and didn't seem to know what Go was.

How does that even happen? It seems bizarre that Manning had this copy editor at all.

I recently had a negative experience with Manning. I sent them an email saying that I'm in the process of writing a book, and I'm self-publishing it, but I was curious about the possibility of applying to Manning for a second edition. I asked whether they accept second editions after a self-published first edition and what document formats they accept.

I got back a form letter telling me that they'd rejected my proposal. When I followed up and said I didn't send a proposal but was asking preliminary questions, they told me that they understood I hadn't sent a proposal, but they were going off of the table of contents on my book's website. I guess they decided to pre-emptively reject me?

They also only said Google Docs as a document format, but based on this blog post, clearly they accept AsciiDoc.

Since you're in here, if I can recommend: sync.Pool with non-fixed-size objects is a source of many problems. https://wundergraph.com/blog/golang-sync-pool as a decent overview, and https://github.com/yarpc/yarpc-go/issues/2355 has been my recent plague.

If you browse around Go's stdlib use of sync.Pool, you'll see a variety of tiered pools with fixed sizes, and many drop anything over a large enough size (sometimes gigantic! as much as 16KB!): https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/...

It's a pretty well-established gotcha, sadly, and https://github.com/teivah/100-go-mistakes/blob/master/src/12... falls right into it.

On the topic of copy editing you raise: I wrote a book in DocBook for Manning in 2010. DocBook is XML, so I structured it with opening / end tags on their own line, content in the middle. As you would with a HTML document.

After copy editing multiple chapters, they sent it back to me with all the content on a single line. I was so incredibly upset that they ditched all my painstaking format that I almost abandoned the project there + then.

It sounds like from your experience that it has barely changed. I ended up moving to self-publishing so I have a greater control over the whole process. I wrote it up long-form here: https://ryanbigg.com/2015/08/my-self-publishing-success-stor...

This book format lends itself very nicely to a book club. I was in one with both new and experienced gophers. The mistakes are great discussion points. The veterans got to share stories when they've made whatever mistake or how they've avoided it over the years. The noobs often made comparisons with other languages.

A little secret about the book is a lot of the "mistakes" are introductions to some aspect of Go worded as a mistake. "Not using fuzzing" and "Not using errgroup" are a couple of examples.

O’Reilly author here. Seems the author stumbled over pitching them the book. You can almost certainly start with an email. Our initial contact with O’Reilly was only an email. We filled out a small form later with the details of the proposal, but it was not laborious. I can also attest that their tooling is great. From any git commit I can generate a full version of the book in any of its supported formats. I wrote all of my part of the book in vim.

Hello fellow Manning author! This book is fantastic. I remember reading through a lot of it a couple years back. Super helpful and it's one of those books you can pick up, grab a nugget or two of good info and come back later.

Now that I'm starting another big Go project I'm going to look at it again.

What I like most about this book is it feels like it's all "real world" stuff. You can tell the author has built a lot with Go and can save you time by telling you were the potholes are. Great stuff!

I got a question about the example shown, the goroutine one marked as #63, I'd copypaste but it's an image.

Is there a reason the common mistake is about goroutines specifically? If I instead just made function closures without launching off goroutines, would they all refer to the same 'i' variable? (I assume it's maybe just that the mistake tends to go hand in hand with goroutine-launching code in a pattern like that).

I'd presume the book would say right after the example :)

But otherwise: the author gets serious respect from me for going through that process, taking feedback and learning how to communicate, i.e. taking "how do I make a good book?" very seriously and trying their best. And also things like for putting their foot down when the problematic copyeditor. I'm almost interested in the book, not for learning about Go but learning about what it looks like when I know the writing has some serious intent behind it to communicate clearly.

This is a lovely write up. I don't have anything real to add in this comment, but somehow just clicking the upvote button doesn't feel like enough.

> I was working in Switzerland, refactoring a C++ legacy codebase...

Such a nice place to work, where you can just decide "Let's implement thing A in a completely new stack for us that shows promise" and then, after some time, say, "Ah... this is too hard, bad decision though. Let's try another one"

Sensei's Library has a collection of pages about mistakes made in Go: <https://senseis.xmp.net/?Mistakes>

Per author, this book started the "100 _ Mistakes and How to Avoid Them" series. That opened a whole new avenue of books based on programming language.

> I learned a ton from my DE. Like, really, a ton. Before that, I had been writing on various blogs for about a decade, but writing online is all about being direct because most people don’t have time. With a book, it’s different. People made a deliberate decision to buy your book. Now, it’s your job to bring them somewhere valuable. And if that takes time (meaning more words), so be it.

I have a hard time with this point. It feels to me like a lot of books have A LOT of unecassery padding all over the place.

The example of taking 28 words and turning it to 120 is pretty good at showing this. The first paragraph is totally pointless - we are reading a book about 100 most common mistakes, obviously this mistake is very common, how did this increased the value?

Then we have another line that explaining what happens in the code, which is totally useless because the code is super trivial.

Then the code, with more explanations on the side as if the previous line was not clear.

And only after that we get to the crux of the issue.

I understand that book publishers feel they need to justify the price of a book by reaching the 300p mark in some or other way, but in my way this only makes the book worse.