A million ways to die from a data race in Go • Hacker News Board

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

#51

Post by gf000 » Tue, Nov 25, 2025, 9:00 AM UTC

marhee wrote: post #41

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.

Concurrent programming is hard and has many pitfalls; people are warned about this from the very, very start. If you then go about it without studying proper usage/common pitfalls and do not use (very) defensive coding practices (violated by all examples) then the main issue is just naivity. No programming language can really defend against that.

You are completely dismissing language design.

Also, these are minimal reproducers, the exact same mistakes can trivially happen in larger codebases across multiple files, where you wouldn't notice them immediately.

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

#52

Post by dontlaugh » Tue, Nov 25, 2025, 9:02 AM UTC

bloppe wrote: post #48

dontlaugh wrote: post #39

Earlier quoted context omitted.

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

Who is "they"? This isn't Rust. It's still up to the developer to follow the advice. Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.

Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually.

It's not like it's a disaster, but it's certainly inconsistent.

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

#53

Post by p2detar » Tue, Nov 25, 2025, 9:06 AM UTC

gf000 wrote: post #33

unscaled wrote: post #12

Earlier quoted context omitted.

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.

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.

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

#54

Post by gf000 » Tue, Nov 25, 2025, 9:07 AM UTC

Mawr wrote: post #38

TheDong wrote: post #13

Earlier quoted context omitted.

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

Java consumes memory because collecting garbage is extra work and under most circumstances it makes no sense to rush it. Meanwhile Go will rather take time away from your code to collect garbage, decreasing throughput. If there is ample memory available, why waste energy on that?

Nonetheless, it's absolutely trivial to set a single parameter to limit memory usage and Java's GCs being absolute beasts, they will have no problem operating more often.

Also, intellij is a whole IDE that caches all your code in AST form for fast lookoup and stuff like that.. it has to use some extra memory by definition (though it's also configurable if you really want to, but it's a classic space vs time tradeoff again).

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

#55

Post by euroderf » Tue, Nov 25, 2025, 9:09 AM UTC

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.

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

#56

Post by ViewTrick1002 » Tue, Nov 25, 2025, 9:14 AM UTC

lenkite wrote: post #43

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.

> Subtle linguistic distinctions are not what I want to see in my docs, especially if the context is concurrency. Which PL do you use then ? Because even Rust makes "Subtle linguistic distinctions" in a lot of places and also in concurrency.

> Because even Rust makes "Subtle linguistic distinctions" in a lot of places and also in concurrency.

Please explain

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

#57

Post by Sharlin » Tue, Nov 25, 2025, 9:17 AM UTC

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…

Async, for better or worse, in 2025 is generally used to refer to the async/await programming model in particular, or more generally to non-blocking interfaces that notify you when they're finished (often leading to the so-called "callback hell" which motivated the async/await model).

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

#58

Post by p2detar » Tue, Nov 25, 2025, 9:19 AM UTC

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.

I'm still relatively new to Go, but I've never seen closures used that often thus far in production code. Is it really a common practice?

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

#59

Post by shaftoe444 » Tue, Nov 25, 2025, 9:23 AM UTC

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

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

#60

Post by bloppe » Tue, Nov 25, 2025, 9:24 AM UTC

dontlaugh wrote: post #52

bloppe wrote: post #48

Earlier quoted context omitted.

Who is "they"? This isn't Rust. It's still up to the developer to follow the advice. Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.

Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually. It's not like it's a disaster, but it's certainly inconsistent.

I don't think allowing developers to use their discretion to share state is "certainly inconsistent". Not sure what your threshold is for "quite hard" but it seems pretty low to me.