5 ms·

> 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_in_go.html#i

by kiitos 10mo ago

> 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_in_go.html#improper-lifetime-of-a-mutex 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_in_go.html#the-fix-2 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..

pipe01 10mo ago
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?
evanelias 10mo ago
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 10mo ago
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.

by kiitos 10mo ago

pipe01 10mo ago

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?

evanelias 10mo ago

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 10mo ago

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.