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

141–146 of 146 posts

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

#141

Post by p2detar »

gf000 wrote: post #91
p2detar wrote: post #85

Earlier quoted context omitted.

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

Silent corruption of unrelated data structures in memory. Segfault only happens if you are accessing memory outside the program's valid address space. But it can just as easily happen that you corrupt something in the runtime, and the GC will run havoc, or cause a million other kind of very hard to debug errors.

> But it can just as easily happen that you corrupt something in the runtime, and the GC will run havoc

I would love to see an example of this, if you don't mind. My understanding is that the GC in Go actively prevents against what you write. There is no pointer arithmetic in the language. The worst that can happen is a segfault or data corruption due to faulty locking like the Java example I gave above.

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

#142

Post by euroderf »

badc0ffee wrote: post #105
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.

Teach the pain away...

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

#143

Post by Mawr »

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…

> If there is ample memory available, why waste energy on that?

Cute argument, but there's no way for a program to know how much memory is available. And there is such a thing as "appropriate amount of memory for this task". Hint: "4GB+" / "unbounded" is not the right answer for an LSP on a > 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.

Cool, then the issues I mentioned should never have existed in the first place. But they did, and probably still do today, I can't test easily. So clearly, they're not so easy to fix for some reason.

Also, this is such programmer-speak. It's trivial to set a single parameter? Absolutely, you just need to know that's what's needed, what the parameter is, how to set it, and what to set it to. Trivial! And how exactly would I, as a user, know any of this?

I'm a decent example here, since I could tell the software is written in Java (guess how), I know about its GC tuning parameters and I could probably figure out what parameters to set. So what exact value should I set? 500MB? 1GB? 2GB? How long should I spend doing trial-and-error?

Now consider you'd be burdening every single user of the program with the above. How about we, as engineers, choose the right program parameters, so that the user doesn't have to do or worry about anything? How about that.

> a classic space vs time tradeoff again

Most of the time, just like here, "it's a tradeoff" is a weasel phrase used to excuse poor engineering. Everything is a tradeoff, so pointing that out says nothing. Tradeoffs have to be chosen wisely too, you know.

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

#144

Post by gf000 »

Mawr wrote: post #143
gf000 wrote: post #54

Earlier quoted context omitted.

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…

> If there is ample memory available, why waste energy on that? Cute argument, but there's no way for a program to know how much memory is available. And there is such a thing as "appropriate amount of memory for this task". Hint: "4GB+" / "unbounded" is not the right answer for an LSP on a > Nonetheless, it's absolutely trivial to set a single parameter to limit memory usage and Java's GCs being absolute beasts, the…

> but there's no way for a program to know how much memory is available

It usually knows the total system RAM available, and within containers it knows the resource limits. So your statement is false.

> And there is such a thing as "appropriate amount of memory for this task"

Appropriate for whom? Who to tell that I want this app to have better throughput and I don't care how much memory it would cost, or that I don't care about slightly lower throughput but I want the least amount of memory used?

> Now consider you'd be burdening every single user of the program with the above

Or you know, just set one as the developer? There is not even such a thing as a JRE anymore, the prevalent way to ship a Java app is with a "JRE" made up from only the modules that the app needs, started with a shell script or so. You can trivially set as a developer your own set of flags and parameters.

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

#145

Post by gf000 »

p2detar wrote: post #141
gf000 wrote: post #91

Earlier quoted context omitted.

Silent corruption of unrelated data structures in memory. Segfault only happens if you are accessing memory outside the program's valid address space. But it can just as easily happen that you corrupt something in the runtime, and the GC will run havoc, or cause a million other kind of very hard to debug errors.

> But it can just as easily happen that you corrupt something in the runtime, and the GC will run havoc I would love to see an example of this, if you don't mind. My understanding is that the GC in Go actively prevents against what you write. There is no pointer arithmetic in the language. The worst that can happen is a segfault or data corruption due to faulty locking like the Java example I gave above.

https://lobste.rs/c/vq3zn0

Here is a thread discussing it, but there are multiple posts/comment threads on the topic. In short, slices are fat pointers in the language, and data races over them can cause other threads to observe the slice in an invalid state, which can be used to access memory it shouldn't be able to.

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

#146

Post by [deleted] »

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…

[deleted]
Post reply on HN