by Kerrick on 4/10/25, 8:47 PM with 130 comments
by mtlynch on 4/10/25, 11:25 PM
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.
by Groxx on 4/11/25, 2:24 AM
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.
by ryanbigg on 4/10/25, 11:44 PM
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...
by onionisafruit on 4/10/25, 9:55 PM
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.
by relistan on 4/11/25, 7:56 AM
by JeremyMorgan on 4/10/25, 9:48 PM
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!
by adeon on 4/10/25, 10:06 PM
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.
by goostavos on 4/10/25, 9:30 PM
by turtleyacht on 4/10/25, 9:43 PM
by re-lre-l on 4/11/25, 10:15 AM
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"
by tmtvl on 4/11/25, 8:31 AM
by m1keil on 4/11/25, 3:34 AM
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.
by pier25 on 4/11/25, 1:09 AM
I've worked with editorial teams and I'd rather have that than PDFs and/or Word files without version control.
by methods21 on 4/11/25, 10:00 PM
On a different note, def. feel you pain regarding the copyeditor.
by meling on 4/10/25, 9:54 PM
by tyho on 4/11/25, 12:22 PM
by musicale on 4/12/25, 1:57 AM
I usually avoid them by not using go. Or waiting until missing features (generics) are added.
by lexoj on 4/11/25, 9:29 AM
by codazoda on 4/11/25, 12:55 AM
by kickbribe on 4/11/25, 2:13 AM
by revskill on 4/11/25, 5:15 AM
by begueradj on 4/11/25, 5:31 AM
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.