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.
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 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>
> 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.
> Adding comments in the source code itself
I've worked with editorial teams and I'd rather have that than PDFs and/or Word files without version control.
"Yet I think Tim’s single review was possibly as valuable as all the others combined".... and yet you don't even tell us anything about his review.... disappointing esp. considering the screenshots/level of details on other input.
On a different note, def. feel you pain regarding the copyeditor.
I read it about two years ago, and would definitely recommend it. It has a similar vibe to Josh Bloch’s Effective Java.
The single example given here is incorrect. Since Go 1.22 loop variables have per-iteration scope, the "broken" code is deterministic and correct.
The go mistakes that tend to bother me the most are things like gc pauses, lack of first-class named and default arguments, lack of exceptions, lack of subrange types, etc.
I usually avoid them by not using go. Or waiting until missing features (generics) are added.
I purchased this book on audible (because it said PDF version as well) but PDF version had only some code and not the entire book. Sorry if this is how Audible works and if its not related to this book per se. Looking forward to listen to it.
If you’re interested in publishing a book, please reach out and let me know what’s blocking you. My email address is in my profile. I’m not selling anything here, I want to understand the issues you’re facing.
As someone interested in learning Go is this great, thank you!
A good language should leave no room for mistakes.
> (to be honest, I was also a significant source of inspiration!)
There is no honesty in praising yourself, no matter what you did and achieved.
Honesty is when you pay tribute to someone else by saying he is a source of inspiration.
>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.