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

81–90 of 146 posts

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

#81

Post by LtWorf »

gf000 wrote: post #76
LtWorf wrote: post #69

Earlier quoted context omitted.

refcounting gc is very fast and works fine for most of the references. Java not using a combination of both methods is a flaw.

Refcounting is significantly slower under most circumstances. You are literally putting a bunch of atomic increments/decrements into your code (if you can't prove that the given object is only used from a single thread) which are crazy expensive operations on modern CPUs, evicting caches.

Under most circumstances function local variables aren't passed to other threads, or passed at all.

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

#82

Post by gf000 »

LtWorf wrote: post #81
gf000 wrote: post #76

Earlier quoted context omitted.

Refcounting is significantly slower under most circumstances. You are literally putting a bunch of atomic increments/decrements into your code (if you can't prove that the given object is only used from a single thread) which are crazy expensive operations on modern CPUs, evicting caches.

Under most circumstances function local variables aren't passed to other threads, or passed at all.

And? That's a small, optional optimization done by e.g. Swift.

Also, I don't know how it's relevant to Go which uses a tracing GC.

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

#83

Post by hgomersall »

Smaug123 wrote: post #27
hgomersall wrote: post #24

Earlier quoted context omitted.

Async and concurrency are orthogonal concepts.

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 runtime), but even that might be strictly serial.

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

#84

Post by logicchains »

ViewTrick1002 wrote: post #20
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

> Go is remarkably easy to be productive in which is what the label on the tin can claims. To feel productive in.

It feels productive because you're not waiting ages for it to compile again after every change.

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

#85

Post by p2detar »

gf000 wrote: post #77
p2detar wrote: post #53

Earlier quoted context omitted.

What is your definition of memory issues? Of course you can have memory corruption in Java. The easiest way is to spawn 2 threads that write to the same ByteBuffer without write locks.

And you would get garbled up bytes in application logic . But it has absolutely no way to mess up the runtime's state, so any future code can still execute correctly. Meanwhile a memory issue in C/Rust and even Go will immediately drop every assumption out the window, the whole runtime is corrupted from that point on. If we are lucky, it soon ends in a segfault, if we are less lucky it can silently cause much bigger…

> Meanwhile a memory issue in C/Rust and even Go will immediately drop every assumption out the window, the whole runtime is corrupted from that point on.

In C, yes. In Rust, I have no real experience. In Go, as you pointed out, it should segfault, which is not great, but still better than in C, i.e., fail early. So I don't get or understand what your next comment means? What is a "less lucky" example in Go?

> If we are lucky, it soon ends in a segfault, if we are less lucky it can silently cause much bigger problems.

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

#86

Post by jerf »

iambvk wrote: post #6

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

Haskell, Erlang/Elixir, and Rust would save you from most of these problems.

Then, of course, there's the languages that are still so deeply single-threaded that they simply can't write concurrency bugs in the first place, or you have to go way out of your way to get to them, not because they're better than Go but because they don't even play the game.

However, it is true the list is short and likely a lot of people taking the opportunity to complain about Go are working in languages where everything they are so excited to complain about are still either entirely possible in their own favorite language (with varying affordances and details around the issues) or they are working in a language that as mentioned simply aren't playing the game at all, which doesn't really count as being any better.

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

#87

Post by reader_1000 »

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.

I agree, any direct / field modification should be assumed to be not-thread safe. OTOH, I think Go made a mistake by exporting http.DefaultClient, because it is a pointer and using it causes several problems including thread safety, and there are libraries that use it. It would have been better if it were http.NewDefaultClient() which creates a new one every time it is called.

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

#88

Post by rowanseymour »

saturn_vk wrote: post #44
Mawr wrote: post #36

Earlier quoted context omitted.

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

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.

I saw that bit about concurrent use of http.Client and immediately panicked about all our code in production hammering away concurrently on a couple of client instances... and then saw the example and thought... why would you think you can do that concurrently??

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

#89

Post by thfuran »

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 pure corporatese.

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

#90

Post by tialaramex »

questioner8216 wrote: post #67
TheDong wrote: post #26

Earlier quoted context omitted.

Yeah, indeed. Developers have a bad habit of adding mutable fields to plain old data objects in Go though, so even if it's immutable now, it's now easy for a developer to create a race down the line. There's no way to indicate that something must be immutability at compile-time, so the compiler won't help you there.

Good points. I have also heard others say the same in the past regarding Go. I know very little about Go or its language development, however. I wonder if Go could easily add some features regarding that. There are different ways to go about it. 'final' in Java is different from 'const' in C++, for example, and Rust has borrow checking and 'const'. I think the language developers of the OCaml language has experimente…

Rust's `const` is an actual constant, like 4 + 1 is a constant, it's 5, it's never anything else, we don't need to store it anywhere - it's just 5. In C++ `const` is a type qualifier and that keyword stands for constant but really means immutable not constant.

This results in things like you can "cast away" C++ const and modify that variable anyway, whereas obviously we can't try to modify a constant because that's not what the word constant means.

In both languages 5 += 3 is nonsense, it can't mean anything to modify 5. But in Rust we can write `const FIVE: i32 = 5;` and now FIVE is also a constant and FIVE += 3 is also nonsense and won't compile. In contrast in C++ altering an immutable "const" variable you've named FIVE is merely forbidden, once we actually do this anyway it compiles and on many platforms now FIVE is eight...

Post reply on HN