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

61–70 of 146 posts

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

#61

Post by dontlaugh »

bayindirh wrote: post #42
dontlaugh wrote: post #39

Earlier quoted context omitted.

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

Threads share the same memory by definition, though. When you isolate these threads from a memory PoV, they become processes. Moreover, threads are arguably useless without shared memory anyway. A thread is invoked to work on the same data structure with multiple "affectors". Coordination of these affectors is up to you. Atomics, locks, queues... The tools are many. In fact, processes are just threads which are isola…

Goroutines aren't posix threads. They could've lacked shared memory by default, which could be enforced by a combination of the compiler and runtime like with Erlang.

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

#62

Post by gspr »

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.

From where I sit (in Norway), it seems to have become standard corporate-speak in any company where English is widely used. They've even started using the directly translated noun "læring" in Norwegian, too. It's equally silly. Both variants are usually spoken by the type of manager who sets out all future directions based on whatever their LinkedIn circle is talking about. It's thus a very valuable word, because the rash it elicits lets me know what people to avoid working with.

I'm not sure if the people who use this word think it's proper English. They rarely seem to care what words mean anyway.

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

#63

Post by dontlaugh »

bloppe wrote: post #60
dontlaugh wrote: post #52

Earlier quoted context omitted.

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.

Goroutines could've lacked shared memory by default, requiring you to explicitly pass in pointers to shared things. That would've significantly encouraged sharing memory by communicating.

The opposite default encourages the opposite behaviour.

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

#64

Post by LtWorf »

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.

The whole point of not using C is that such pitfalls shouldn't compile in other languages.

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

#65

Post by kryptiskt »

bayindirh wrote: post #35
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.

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

> Using a tool knowing its modus operandi is not "pretending the problems don't exist".

I said that in response to the hostility ("crap on Go") towards the article. If such articles aren't written, how will newbies learn about the pitfalls in the first place?

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

#67

Post by questioner8216 »

TheDong wrote: post #26
questioner8216 wrote: post #23

Earlier quoted context omitted.

For that last example, if 'item' is immutable, there is no issue, correct?

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 experimented with something inspired by Rust regarding concurrency.

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

#68

Post by euroderf »

shaftoe444 wrote: post #59
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

lettuce not forget strategerise/strategery

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

#69

Post by LtWorf »

gf000 wrote: post #54
Mawr wrote: post #38

Earlier quoted context omitted.

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

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

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

#70

Post by [deleted] »

p2detar wrote: post #58
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?

[deleted]
Post reply on HN