[adeon]

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]

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.

[adeon]

So not only do you write a full book, but you keep the content online, up to date by making sure readers are informed of new developments that might make advice irrelevant? And you are able on the spot to say "one of three mistakes that are not relevant anymore"? You impress me, random book-writing Internet person.

You give me a feeling you really care about the craft and just making a good useful resource, which what I respect. I looked around the site and bookmarked it as a technical writing example I might go to read around now and then.

I sometimes teach coding or general computing things (but hands-on, less about writing) and I've come to appreciate that sometimes it is extraordinarily difficult to educate on or communicate complicated ideas.

Quoting you: To give you a sense of what I mean by improving the book “over and over“, keep in mind that between feedback from my DE, external reviewers, and others, there are parts of the book that I rewrote more than ten times.

I also do rewriting especially with content I intend to be a resource or education piece. Obsessively rewrite. Make it shorter. Clearer. Oops that reads like crap let's start over. IMO having an urge to do this and address all feedback or your own itches means you care about your work. Just have to remind myself that that perfect is the enemy of good enough (or something like that I forgot if the expression went exactly like that).

[Cthulhu_]

If you'd ever write a follow-up, would you just remove "mistakes" and end up with the book "86 Go mistakes and how to avoid them", or find more?

[ljm]

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.

[amarshall]

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]

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).

[ljm]

It's literally the same problem with closures and scope that JS has.

You think you're working with a value but you're actually working with a reference to a value under the hood.

[kbolino]

It was definitely 1. There were ways to demonstrate the issue without involving goroutines, such as by creating a list of closures in a loop, one at each iteration, and then invoking them synchronously after the loop exits. They would all have the same (in this case, final) value of i.

[teivah]

#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.