[kiitos]

> I have been writing production applications in Go for a few years now.

sorry, what?

https://gaultier.github.io/blog/a_million_ways_to_data_race_...

this code is obviously wrong, fractally wrong

why would you create a new PricingService for every request? what makes you think a mutex in each of those (obviously unique) PricingService values would somehow protect the (inexplicably shared) PricingInfo value??

> the fix

https://gaultier.github.io/blog/a_million_ways_to_data_race_...

what? this is in no way a fix to the problem.

it's impossible to believe the author's claims about their experience in the language, this is just absolute beginner stuff..

[evanelias]

I had a similar reaction to that, glad it's not just me.

Meanwhile with the 4th item, this whole example is gross, repeatedly polling a buffer every 100ms is a massive red flag. And as for the data race in that item, the idiomatic fix is to just use io.Pipe, which solves the entire problem far more cleanly than inventing a SyncWriter.

The author's last comment regarding "It would also be nice if more types have a 'sync' version, e.g. SyncWriter, SyncReader, etc" probably indicates there's some fundamental confusion here about idiomatic Go.

[scoodah]

Yeah this whole section of the article threw me all the way off. What even is this code? There’s so many things wrong with it, it blows my mind.

About the only code example I saw in here and thought “yeah it sucks when that happens” is the accidental closure example. Accidentally shadowing something you’re trying to assign to in a branch because you need to handle an error or accidentally reassigning something can be subtle. But it’s pretty 101 go.

The rest is… questionable at best.

[pipe01]

That fix really confused me as well. Not only does the code behave differently from the problematic code, but why do they even need the mutex at that point?