[HN Gopher] So, I Wrote a Book: The Story Behind "100 Go Mistake...
___________________________________________________________________
So, I Wrote a Book: The Story Behind "100 Go Mistakes and How to
Avoid Them"
Author : Kerrick
Score : 95 points
Date : 2025-04-10 20:47 UTC (2 hours ago)
(HTM) web link (www.thecoder.cafe)
(TXT) w3m dump (www.thecoder.cafe)
| goostavos wrote:
| 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.
| 4ndrewl wrote:
| Just came here to write exactly the same!
| teivah wrote:
| Thank you!
| teivah wrote:
| I just noticed my post was on HN. Thank you very much :)
| timbit42 wrote:
| Any language that needs a book with such a title sounds like a
| failed language. This is worse than, "JavaScript: The good
| parts".
| quaunaut wrote:
| I'm not a big fan of Go, and I think you could write this about
| nearly any language.
| ziddoap wrote:
| You can make 100 mistakes in literally every language.
| teivah wrote:
| Agreed. That was also my point when I mentioned the book
| started the "100 ${LANGUAGE} Mistakes and How to Avoid Them"
| series at Manning.
| ninetyninenine wrote:
| There's an infinite amount of mistakes in every language.
| Obviously the meaning behind this is mistakes only makeable
| in golang.
| onionisafruit wrote:
| I'd love to try a language that you couldn't write a similar
| book about. Any suggestions?
| 9rx wrote:
| Why would anyone take time to write a book like that for a
| failed language?
| ninetyninenine wrote:
| Because they don't know it's failed.
| wesselbindt wrote:
| Maybe because you're stuck with it because a bunch of
| software has already been written in it, in need of
| maintenance and extension. Or maybe because the browser only
| runs javascript.
| 9rx wrote:
| Meaning that the language didn't fail at all, but the exact
| opposite? Javascript, of all the languages ever created, is
| quite likely the language that has failed the least.
| grepexdev wrote:
| Could you let me know what language doesn't have _at least_ 100
| common mistakes across a broad range of developers with varying
| skill level?
| ninetyninenine wrote:
| Did you know there exists languages that don't have run time
| errors? Languages that you can never crash outside of an OOM.
|
| That means you can't find a language with no mistakes. But
| across all languages there are languages with astronomically
| more gotchas and mistakes then others.
|
| Golang is one of these languages that is astronomical. I mean
| just compare it to the language with zero runtime errors.
| 9rx wrote:
| _> Did you know there exists languages that don 't have run
| time errors?_
|
| Probably not. All those languages failed.
| tmountain wrote:
| Elm.
| Philpax wrote:
| It "succeeded" in that it delivers on its promise and
| some people still use it, but it is largely dead now due
| to the lack of development and the community's inability
| to push the language itself forward. There are forks that
| address that, but Elm itself seems unlikely to Lazarus
| any time soon.
|
| It's definitely proof that software can be written in
| such a regime, though, and I hope we see something
| similarly dogmatic some day.
| 9rx wrote:
| Failed language. And for that reason few know it exists.
| Thaxll wrote:
| There is no such language, even Rust has many footguns.
| 9rx wrote:
| There is such languages, but they actually failed, so
| you've probably never heard of them.
| teivah wrote:
| That's why Manning will consider a 100 Rust Mistakes
| edition.
| JeremyMorgan wrote:
| Disagree. Every language has quirks, and best practices.
| ninetyninenine wrote:
| Every language has mistakes. But it's also 100% true that many
| languages have more mistakes then others.
| wesselbindt wrote:
| A lot of replies to your comment conflate possibility with
| necessity. Could and need are different things.
| Barrin92 wrote:
| It sounds like the opposite, a language popular and practical
| enough to the point where people actually use it across a wide
| range of cases and skillsets.
|
| The reason why the books don't exist for <highbrow language of
| choice> is because there's only 50 programs written in it, 49
| of which are tooling for the language.
| turtleyacht wrote:
| 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.
| JeremyMorgan wrote:
| 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!
| meling wrote:
| I read it about two years ago, and would definitely recommend it.
| It has a similar vibe to Josh Bloch's Effective Java.
| onionisafruit wrote:
| 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.
| adeon wrote:
| 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.
| teivah wrote:
| More details here: https://100go.co/#not-being-careful-with-
| goroutines-and-loop.... My example was probably terrible as
| it's one of the three mistakes in the book that aren't relevant
| anymore, thanks to Go's recent updates.
|
| Thank you very much for your comment, though. It means a lot.
| ljm wrote:
| I think #633 must be a typo, or just a fumbled explanation.
|
| "We might expect this code to print 123 in no particular order"
| should really say "exactly" or "in order", since it's proved in
| the next paragraph to be inconsistent.
|
| And that would be the layman's explanation of concurrency
| resulting in things added sequentially happening out of order.
|
| And assuming FIFO on async execution, akin to running
| everything in series, is probably the first mistake anyone will
| make when they encounter concurrency for the first time.
| teivah wrote:
| #63 isn't about the lack of execution guarantees when you
| execute multiple goroutines without proper synchronization;
| it was related to loop variables and goroutines.
| amarshall wrote:
| The problem isn't that they might be out-of-order. The
| problem is expecting that they merely might be out-of-order
| and actually getting missed and duplicated values due to the
| timing of shared memory access. This was enough of a problem
| that they [changed the behavior][1] in Go 1.22.
|
| [1]: https://go.dev/blog/loopvar-preview
| adeon wrote:
| Yes, that was the crux of my question (and was answered by
| that link when I checked teivah-given link, which linked
| https://go.dev/blog/loopvar-preview right there as well).
| Basically I wondered if the example given was really about:
|
| 1) In Go, the 'i' variable in the for loop is the same 'i'
| for each round of the iteration, meaning closures created
| inside the loop all refer to that same 'i' variable,
| instead of getting their own copy of it. Very easy to
| accidentally think the all closures have their own copy of
| 'i'. Goroutines are only mentioned because in Golang this
| mistake tends to come up with Goroutines because of a
| common code pattern.
|
| OR
|
| 2) Goroutines themselves either behave or have some weird
| lexical scope rules in a way I don't know and it doesn't
| really have to do with closures but an entirely Golang-
| foreign-alien concept to me I cannot see, and this is why
| the book example had Goroutines mentioned with the mistake.
|
| I rarely write Go myself so I was curious :) It looks like
| it was 1) unless I am bad at reading, and I think the Go
| 1.22 change is good. I could easily imagine myself and
| others making that mistake even with the knowledge to be
| careful around this sort of code (the link shows a more
| complicated example when scrolling down that IMO is a good
| motivating example).
| tsukikage wrote:
| ...anyone else click the link expecting it to be about board game
| strategy before realising they were on the wrong site for that?
___________________________________________________________________
(page generated 2025-04-10 23:00 UTC)