Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A million ways to die from a data race in Go

gaultier.github.io

Post reply on HN
Print view View original

31–40 of 146 posts

Re: A million ways to die from a data race in Go

#31

Post by broken_broken_ »

rustystump wrote: post #18

On a phone and the formatting of the snippets is unreadable with the 8 space tabs… That said, i think about all languages have their own quirks and footguns. I think people sometimes forget that tools are just that, tools. Go is remarkably easy to be productive in which is what the label on the tin can claims. It isnt “fearless concurrency” but get shit done before 5 pm because traffics a bitch on Wednesdays

Author here, thanks for the feedback on legibility, I have now just learned about the CSS `tab-size` property to control how much space tabs get rendered with. I have reduced it, should be better now.

Re: A million ways to die from a data race in Go

#32

Post by gethly »

Every language has an arsenal of footguns. Go is no different. I would say that overall it is not too bad, comparatively.

From all the listed cases, only the first one is easy to get caught by, even as an experienced developer. There, the IDE and syntax highlighting is of tremendous help and for general prevention. The rest is just understanding the language and having some practice.

Re: A million ways to die from a data race in Go

#33

Post by gf000 »

unscaled wrote: post #12
iambvk wrote: post #6

Only looked at the first two examples. No language can save you when one writes bad code like that.

You can argue about how likely is code like that is, but both of these examples would result in a hard compiler error in Rust. A lot of developers without much (or any) Rust experience get the impression that the Rust Borrow checker is there to prevent memory leaks without requiring garbage collection, but that's only 10% of what it does. Most the actual pain dealing with borrow checker errors comes from it's other j…

But even so, the JVM has well-defined data races that may cause logical problems, but can never cause memory issues.

That's not the case with Go, so these are significantly worse than both Rust and Java/C#, etc.

Re: A million ways to die from a data race in Go

#34

Post by Someone »

questioner8216 wrote: post #14

I dislike some of this article, my impression is similar to some of the complaints of others here. However, are Go programs not supposed to typically avoid sharing mutable data across goroutines in the first place? If only immutable messages are shared between goroutines, it should be way easier to avoid many of these issues. That is of course not always viable, for instance due to performance concerns, but in theory…

> However, are Go programs not supposed to typically avoid sharing mutable data across goroutines in the first place?

C programmers aren’t supposed to access pointers after freeing them, either.

“Easy to do, even in clean-looking code, but you shouldn’t do it” more or less is the definition of a pitfall.

Re: A million ways to die from a data race in Go

#35

Post by bayindirh »

kryptiskt wrote: post #17
bilbo-b-baggins wrote: post #2

[flagged]

To me it looks like simple, clear examples of potential issues. It's unfortunate to frame that as "crapping on Go", how are new Go programmers going to learn about the pitfalls if all discussion of them are seen as hostility? Like, rightly or wrongly, Go chose pervasive mutability and shared memory, it inevitably comes with drawbacks. Pretending they don't exist doesn't make them go away.

> Pretending they don't exist doesn't make them go away.

It's generally assumed that people who defend their favorite programming language are oblivious to the problems the language has or choose to ignore these problems to cope with the language.

There's another possibility: Knowing the footguns and how to avoid them well. This is generally prevalent in (Go/C/C++) vs. Rust discussions. I for one know the footguns, I know how bad it can be, and I know how to avoid them.

Liking a programming language as is, operating within its safe-envelope and pushing this envelope with intent and care is not a bad thing. It's akin to saying that using a katana is bad because you can cut yourself.

We know, we accept, we like the operating envelope of the languages we use. These are tools, and no tool is perfect. Using a tool knowing its modus operandi is not "pretending the problems don't exist".

Re: A million ways to die from a data race in Go

#36

Post by Mawr »

minus7 wrote: post #28

All code is inherently not concurrency-safe unless it says so. The http.Client docs mention concurrent usage is safe, but not modification. The closure compiler flag trick looks interesting though, will give this a spin on some projects.

> The http.Client docs mention concurrent usage is safe, but not modification.

Subtle linguistic distinctions are not what I want to see in my docs, especially if the context is concurrency.

Re: A million ways to die from a data race in Go

#37

Post by bloppe »

kryptiskt wrote: post #17
bilbo-b-baggins wrote: post #2

[flagged]

To me it looks like simple, clear examples of potential issues. It's unfortunate to frame that as "crapping on Go", how are new Go programmers going to learn about the pitfalls if all discussion of them are seen as hostility? Like, rightly or wrongly, Go chose pervasive mutability and shared memory, it inevitably comes with drawbacks. Pretending they don't exist doesn't make them go away.

Go famously summed up their preferred approach to shared state:

> Don't communicate by sharing memory; share memory by communicating.

Re: A million ways to die from a data race in Go

#38

Post by Mawr »

TheDong wrote: post #13
xlii wrote: post #9

Earlier quoted context omitted.

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.

"best in class"? I feel like Java's IDE support is best in class. I feel like go is firmly below average. Like, Java has great tooling for attaching a debugger, including to running processes, and stepping through code, adding conditional breakpoints, poking through the stack at any given moment. Most Go developers seem to still be stuck in println debugging land, akin to what you get in C. The gopls language server…

> The gopls language server generally takes noticeably more memory and cpu than my IDE requires for a similarly sized java project

Okay, come on now :D Absolutely everything around Java consumes gigabytes of memory. The culture of wastefulness is real.

The Go vs Java plugins for VSCode are no comparison in terms of RAM usage.

I don't know how much the Go plugin uses, which is how it should be for all software — means usage is low enough I never had to worry about it.

Meanwhile, my small Java projects get OOM killed all the time during what I assume is the compilation the plugin does in the background? We're talking several gigabytes of RAM being used for... ??? I'm not exactly surprised, I've yet to see Java software that didn't demand gigabytes as a baseline. InteliJ is no different btw, asinine startup times during which RAM usage baloons.

Re: A million ways to die from a data race in Go

#39

Post by dontlaugh »

bloppe wrote: post #37
kryptiskt wrote: post #17

Earlier quoted context omitted.

To me it looks like simple, clear examples of potential issues. It's unfortunate to frame that as "crapping on Go", how are new Go programmers going to learn about the pitfalls if all discussion of them are seen as hostility? Like, rightly or wrongly, Go chose pervasive mutability and shared memory, it inevitably comes with drawbacks. Pretending they don't exist doesn't make them go away.

Go famously summed up their preferred approach to shared state: > Don't communicate by sharing memory; share memory by communicating.

Which they then failed to follow, especially since goroutines share memory with each other.

Re: A million ways to die from a data race in Go

#40

Post by littlestymaar »

bilbo-b-baggins wrote: post #2

[flagged]

During the short time I was working on a Go project I spent a significant amount of time debugging an issue like the one described in his first example in a library we depended on, so it's definitely not a problem of “super convoluted example”.
Post reply on HN