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

101–110 of 146 posts

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

#101

Post by exasperaited »

exasperaited wrote: post #95
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.

It's not a Britishism particularly. My sense was it is coming in part from Indian Standard English but it may well be European english mistranslation. I rather like it, actually. Not least because it is the reciprocal of "teachings", which is long established usage. "What are the asks" and "what's the offer" are turning up much more than I'd like, and they annoy me. But not as much as other Americanisms: "concerning"…

The other day the varying meaning of "lolly" came up in a discussion. In the UK, when it's not a slang term for money, a "lolly" is either a sticky sweet (candy) on a stick, or a frozen treat on a stick. From "lollipop" and then a shortening of "ice lolly".

In Australia, a "lolly" is more or less any non-chocolate-based sweet (candy).

British people find this confusing in Australia, but this is a great example of a word whose meaning was refined in the UK long after we started transporting people to Australia. Before that, a "lollipop" was simply a boiled treacle sweet that might or might not have been on a stick; some time after transportation started, as the industrialised confectionary industry really kicked off, the British English meaning of the word slowly congealed around the stick, and the Australian meaning did not.

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

#102

Post by exasperaited »

dmoy wrote: post #98
shaftoe444 wrote: post #59

Earlier quoted context omitted.

I'm English and "learnings" is one piece of corporate speak that really annoys me. It just means "lessons", for people apparently unaware that noun already exists. British corpo drones seem to need their verb/noun pairs to be identical like action/action learnings/learning trainings/training asks/ask strategising/strategy

I gotta say, of all the corpo speak things, the whole verb/noun normalizing thing is maybe the least distasteful to me. Not that I particularly like it, but compared to all the other stuff it at least seems tolerable. The penchant for deflecting questions and not answering directly, the weasel wording done to cover your ass, the use of words to mean something totally other than the word (e.g. "I take full responsibil…

"In the end I did what I believed was right" meaning "I concede I did not do the right thing but accept no blame".

Mind you there are so many expressions like this and we British are masters of them, like "with the greatest of respect,", which conveys meaning slightly more severe than "you are a total fucking idiot and".

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

#103

Post by pclmulqdq »

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.

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

#104

Post by kiitos »

Mawr wrote: post #36
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.

the distinction between "concurrent use" and "concurrent modification" in go is in no way subtle

there is this whole demographic of folks, including the OP author, who seem to believe that they can start writing go programs without reading and understanding the language spec, the memory model, or any core docs, and that if the program compiles and runs that any error is the fault of the language rather than the programmer. this just ain't how it works. you have to understand the thing before you can use the thing. all of the bugs in the code in this blog post are immediately obvious to anyone who has even a basic understanding of the rules of the language. this stuff just isn't interesting.

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

#105

Post by badc0ffee »

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.

I like to think it dates from 2000 when we had The Teaches of Peaches.

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

#106

Post by badc0ffee »

silisili wrote: post #29
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…

Go is a weird one, because it's super easy to learn -if- you're familiar with say, C. If you're not, it still appears to be super easy to learn, but has enough pitfalls to make your day bad. I feel like much of the article falls into the latter camp. I recently worked with a 'senior' Go engineer. I asked him why he never used pointer receivers, and after explaining what that meant, he said he didn't really understand…

He must have been a senior in some other sense, not in Go experience.

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

#107

Post by hmry »

pbohun wrote: post #97

The first Go proverb Rob Pike listed in his talk "Go Proverbs" was, "Don't communicate by sharing memory, share memory by communicating." Go was designed from the beginning to use Tony Hoare's idea of communicating sequential processes for designing concurrent programs. However, like any professional tool, Go allows you to do the dangerous thing when you absolutely need to, but it's disappointing when people insist o…

> people insist on using the dangerous way and then blame it on the language

Can you blame them when the dangerous way uses 0 syntax while the safe way uses non-0 syntax? I think it's fine to criticize unsafe defaults, though of course it would not be fair to treat it like it's the only option

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

#108

Post by aallaall »

hgomersall wrote: post #83
Smaug123 wrote: post #27

Earlier quoted context omitted.

Could you give an example to distinguish them? Async means not-synchronous, which I understand to mean that the next computation to start is not necessarily the next computation to finish. Concurrent means multiple different parts of the program may make progress before any one of them finishes. Are they not the same? (Of course, concurrency famously does not imply parallelism, one counterexample being a single-threa…

If you are waiting for a hardware interrupt to happen based on something external happening, then you might use async. The benefit is primarily to do with code structure - you write your code such that the next thing to happen only happens when the interrupt has triggered, without having to manually poll completion. You might have a mechanism for scheduling other stuff whilst waiting for the interrupt (like Tokio's r…

So async enable concurrent outstanding requests.

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

#110

Post by kiitos »

gf000 wrote: post #49
saturn_vk wrote: post #44

Earlier quoted context omitted.

On the other hand, it should be very obvious for anyone that has experience with concurrency, that changing a field on an object like the author showed can never be safe in a concurrency setting. In any language.

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 only care about if ANY of the threads have finished execution"

as that claim only holds when the memory model allows it

which is not true in general, and definitely not true in go

assumptions everywhere!!

Post reply on HN