A million ways to die from a data race in Go
gaultier.github.io
A million ways to die from a data race in Go
1–10 of 146 posts
Re: A million ways to die from a data race in Go
#2[flagged]
Re: A million ways to die from a data race in Go
#3[flagged]
I assume you are aware of "the billion dollar mistake" from Tony Hoare?
Re: A million ways to die from a data race in Go
#4In the first one, he complains that one character is enough to cause an issue, but the user should really have a good understanding of variable scope and the difference between assignment and instsntiation if they're writing concurrent go code. Some ides warn the user when they do this with a different color.
Races with mutexes can indicate the author either doesn't understand or refuses to engage with Go's message based concurrency model. You can use mutexes but I believe a lot of these races can be properly avoided using some of the techniques discussed in the go programming language book.
Re: A million ways to die from a data race in Go
#5In the first one, he complains that one character is enough to cause an issue, but the user should really have a good understanding of variable scope and the difference between assignment and instsntiation if they're writing concurrent go code. Some ides warn the user when they do this with a different color. Races with mutexes can indicate the author either doesn't understand or refuses to engage with Go's message b…
>he complains that one character is enough
He complains that language design offers no way of avoiding it (in this particular case) and relies only on human or ide. Humans are not perfect and should not be a requirement to write good code.
Re: A million ways to die from a data race in Go
#6Only looked at the first two examples. No language can save you when one writes bad code like that.
Re: A million ways to die from a data race in Go
#7[flagged]
First sentence:
>I have been writing production applications in Go for a few years now. I like some aspects of Go. One aspect I do not like is how easy it is to create data races in Go.
Their examples don't seem terribly convoluted to me. In fact, Uber's blog post is quite similar: https://www.uber.com/blog/data-race-patterns-in-go/
Re: A million ways to die from a data race in Go
#8[deleted]
Re: A million ways to die from a data race in Go
#9In the first one, he complains that one character is enough to cause an issue, but the user should really have a good understanding of variable scope and the difference between assignment and instsntiation if they're writing concurrent go code. Some ides warn the user when they do this with a different color. Races with mutexes can indicate the author either doesn't understand or refuses to engage with Go's message b…
>he complains that one character is enough He complains that language design offers no way of avoiding it (in this particular case) and relies only on human or ide. Humans are not perfect and should not be a requirement to write good code.
Whatever the case Go's tooling (i.e. IDE part) is one of the best in class and I think it shouldn't be be dismissed in the context of some footguns that Go has.
Re: A million ways to die from a data race in Go
#10Only looked at the first two examples. No language can save you when one writes bad code like that.
[deleted]