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

111–120 of 146 posts

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

#111

Post by ascendantlogic »

> "Go is often touted for its ease to write highly concurrent programs. However, it is also mind-boggling how many ways Go happily gives us developers to shoot ourselves in the foot."

In my career I've found that if languages don't allow developers to shoot themselves (and everyone else) in the foot they're labelled toy languages or at the very least "too restrictive". But the moment you're given real power someone pulls the metaphorical trigger, blows their metaphorical foot off and then starts writing blog posts about how dangerous it is.

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

#112

Post by [deleted] »

lenkite wrote: post #46
gethly wrote: post #32

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.

The first one should be caught by the Go race detector AFAIK. It will warn about the conflicting write accesses to err when both goroutines run.

[deleted]

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

#113

Post by lenkite »

aystatic wrote: post #100
lenkite wrote: post #94

Earlier quoted context omitted.

Runtime borrow checking: RefCell and Rc . Can give other examples, but admittedly they need `unsafe` blocks. Anyways, the article author lacks basic reading skills, since he forgot to mention that the Go http doc states that only the http client transport is safe for concurrent modification . There is no "subtlety" about it. It directly says so. Concurrent "use" is not Concurrent "modification" in Go. The Go stdlib d…

> Runtime borrow checking: RefCell and Rc . Can give other examples, but admittedly they need `unsafe` blocks. Where are the “subtle linguistic distinctions”? These types do two completely different things. And neither are even capable of being used in a multithreaded context due to `!Sync` (and `!Send` for Rc and refguards)

I did say "runtime borrow checking" ie using them together. Example: `Rc::new(RefCell::new(value));`. This will panic at runtime. Maybe I should have used the phrase "dynamic borrowing" ?

https://play.rust-lang.org/?version=stable&mode=debug&editio...

You don't need different threads. I said concurrency not multi-threading. Interleaving tasks within the same thread (in an event loop for example) can cause panics.

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

#114

Post by [deleted] »

aystatic wrote: post #100
lenkite wrote: post #94

Earlier quoted context omitted.

Runtime borrow checking: RefCell and Rc . Can give other examples, but admittedly they need `unsafe` blocks. Anyways, the article author lacks basic reading skills, since he forgot to mention that the Go http doc states that only the http client transport is safe for concurrent modification . There is no "subtlety" about it. It directly says so. Concurrent "use" is not Concurrent "modification" in Go. The Go stdlib d…

> Runtime borrow checking: RefCell and Rc . Can give other examples, but admittedly they need `unsafe` blocks. Where are the “subtle linguistic distinctions”? These types do two completely different things. And neither are even capable of being used in a multithreaded context due to `!Sync` (and `!Send` for Rc and refguards)

[deleted]

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

#115

Post by 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..

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

#116

Post by aystatic »

lenkite wrote: post #113
aystatic wrote: post #100

Earlier quoted context omitted.

> Runtime borrow checking: RefCell and Rc . Can give other examples, but admittedly they need `unsafe` blocks. Where are the “subtle linguistic distinctions”? These types do two completely different things. And neither are even capable of being used in a multithreaded context due to `!Sync` (and `!Send` for Rc and refguards)

I did say "runtime borrow checking" ie using them together . Example: `Rc::new(RefCell::new(value));`. This will panic at runtime. Maybe I should have used the phrase "dynamic borrowing" ? https://play.rust-lang.org/?version=stable&mode=debug&editio... You don't need different threads. I said concurrency not multi-threading . Interleaving tasks within the same thread (in an event loop for example) can cause panics.

I understand what you meant (but note that allocating an Rc isn’t necessary; &RefCell would work just fine). I just didn’t see the “subtle linguistic distinctions” - and still don’t… maybe you could point them out for me?

https://doc.rust-lang.org/stable/std/cell/struct.RefCell.htm...

https://doc.rust-lang.org/stable/std/cell/struct.RefCell.htm...

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

#117

Post by pipe01 »

kiitos wrote: post #115

> 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 fi…

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?

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

#118

Post by gf000 »

kiitos wrote: post #110
gf000 wrote: post #49

Earlier quoted context omitted.

This is not true in the general case. E.g. setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution. It depends on the platform though (e.g. in Java it is guaranteed that there is no tearing [1]). [1] In OpenJDK. The JVM spec itself only guarantees it for 32-bit primitives and references, but given that…

> setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution. this only works when the language defines a memory model where bools are guaranteed to have atomic reads and writes so you can't make a claim like "setting a field to true from ... multiple threads ... can be a meaningful operation e.g. if you…

> can never be safe in a concurrency setting. In any language.

Then I give an example of a language where it's safe

I don't get your point. The negation of all is a single example where it doesn't apply.

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

#119

Post by xnoreq »

ascendantlogic wrote: post #111

> "Go is often touted for its ease to write highly concurrent programs. However, it is also mind-boggling how many ways Go happily gives us developers to shoot ourselves in the foot." In my career I've found that if languages don't allow developers to shoot themselves (and everyone else) in the foot they're labelled toy languages or at the very least "too restrictive". But the moment you're given real power someone p…

Though a good language would point out that what the junior (or in some cases even senior) dev is holding in their hand is in fact a gun and not a gun disguised and marketed as this nice and easy to use toy, which is especially true for Go.

One must keep in mind that devs manage to implement even flawed logic that is directly reflected by the code. I'd rather not give them a non-thread safe language that provides a two letter keyword to start a concurrent thread in the same address space. Insane language design.

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

#120

Post by euroderf »

pclmulqdq wrote: post #103
euroderf wrote: post #55

OT: This page uses the term "Learnings" a lot. As a Murrcan in tech comms in Europe, I always corrected this to something else. But, well, is it some sort of Britishism ? Or is it some weird internet usage that is creeping into general usage ? Likewise for "Trainings". Looks weird to Murrcan eyes but maybe it's a Britishism.

"Learnings" is a piece of corpspeak derived from Indian English. I believe "trainings" also has the same origin.

Please elucidate! Maybe a URL?
Post reply on HN