Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no memory safety without thread safety

ralfj.de

Post reply on HN
Print view View original

91–100 of 517 posts

Re: There is no memory safety without thread safety

#91

Post by Mawr »

zozbot234 wrote: post #44
jchw wrote: post #30

Earlier quoted context omitted.

I think the true answer is that the moment you have to do tricky concurrency in Go, it becomes less desirable. I think that Go is still better at tricky concurrency than C, though there are some downsides too (I think it's a bit easier to sneak in a torn read issue in Go due to the presence of fat pointers and slice headers everywhere.) Go is really good at easy concurrency tasks, like things that have almost no shar…

> And frankly, a lot of software I write is just boring, and Go does fine for a lot of that. I try Rust periodically for things, and romantically it feels like it's the closest language to "the future", but I think the future might still have a place for languages like Go. It's not so much about being "boring" or not; Rust does just fine at writing boring code once you get familiar with the boilerplate patterns (Real…

> (Real-world experience has shown that Rust is not really at a disadvantage wrt. productivity or iteration speed).

I don't believe that for a second. Even just going from Python to Go drops my productivity by maybe about 50%. Rust? Forget it.

Sure, if you have a project that demands correctness and high performance that requires tricky concurrency to achieve, something like Rust may make sense. Not for your run-of-the-mill programs though.

Re: There is no memory safety without thread safety

#92

Post by Thaxll »

zozbot234 wrote: post #83
Thaxll wrote: post #81

Go is memory safe by the most common definition, does not matter if you have segfault in some scenario. How many exploits or security issues have there been related to data race on dual word values? I work with Go for the last 10 years and I never heard of such issues. Not a single time.

The most common definition of memory safe is literally "cannot segfault" (unless invoking some explicitly unsafe operation - which is not the case here unless you think the "go" keyword should be unsafe).

I don't know the NSA with their white house paper about memory safe language mentioned Go, maybe you should tell that there are wrong.

Re: There is no memory safety without thread safety

#93

Post by pjmlp »

shadowgovt wrote: post #74
chadaustin wrote: post #62

Every time this conversation comes up, I'm reminded of my team at Dropbox, where it was a rite of passage for new engineers to introduce a segfault in our Go server by not synchronizing writes to a data structure. Swift has (had?) the same issue and I had to write a program to illustrate that Swift is (was?) perfectly happy to segfault under shared access to data structures. Go has never been memory-safe (in the Rust…

Mostly because it was a remarkable improvement over what came before (and what came before was hilariously fragile).

Only for those not paying attention outside mainstream, or too young to remember former languages.

Re: There is no memory safety without thread safety

#94

Post by Calavar »

kstrauser wrote: post #85
Mawr wrote: post #80

Earlier quoted context omitted.

Safety isn't binary, so your comment makes no sense.

I’d argue that unsafety is binary. If a normal eng doing normal things can break it without going out of their way to deliberately fool the compiler or runtime, I’d call it unsafe.

By that definition Rust also counts as unsafe. Even managed languages like C# and Java would be unsafe.

Re: There is no memory safety without thread safety

#95

Post by 9rx »

pjmlp wrote: post #90
chadaustin wrote: post #62

Every time this conversation comes up, I'm reminded of my team at Dropbox, where it was a rite of passage for new engineers to introduce a segfault in our Go server by not synchronizing writes to a data structure. Swift has (had?) the same issue and I had to write a program to illustrate that Swift is (was?) perfectly happy to segfault under shared access to data structures. Go has never been memory-safe (in the Rust…

It is kind of wild that for a 21st century programming language, the amount of stuff in Go that should have been but never was, but hey Docker and Kubernetes.

On the flip side, what would be the point? There are already a million other languages that have everything and the kitchen sink.

Not going down the same road is the only reason it didn't end up on the pile of obscure languages nobody uses.

Re: There is no memory safety without thread safety

#96

Post by tialaramex »

gpderetta wrote: post #69
gliptic wrote: post #61

Earlier quoted context omitted.

The evaluation order is _unspecified_, not undefined behaviour.

Interestingly, at least in C++, this was changed in the recent past. It used to be that evaluation of arguments was not sequenced at all and if any evaluation touched the same variable, and at least one was a write, it was UB. It was changed as part of the C++11 memory model and now, as you said, there is a sequenced-before order, it is just unspecified which one it is. I don't know much about C, but I believe it was…

Sure, prior to the C++ 11 memory model there just isn't a memory ordering model in C++ and all programs in either C or C++ which would need ordering for correctness did not have any defined behaviour in the language standard.

This is very amusing because that means in terms of the language standard Windows and Linux, which both significantly pre-date C++ 11 and thus its memory model, were technically relying on Undefined Behaviour. Of course, as operating systems they're already off piste because they're full of raw assembly and so on.

Linux has its own ordering model as a result, pre-dating the C++ 11 model. Linus is writing software for multi-processor computers more than a decade before the C++ 11 model so obviously he can't wait around for that.

[Edit: Corrected Linux -> Linux when talking about the man]

Re: There is no memory safety without thread safety

#97

Post by TheDong »

advisedwang wrote: post #3

Wow that's a really big gotcha in go! To be fair though, go has a big emphasis on using its communication primitives instead of directly sharing memory between goroutines [1]. [1] https://go.dev/blog/codelab-share

Even if you use channels to send things between goroutines, go makes it very hard to do so safely because it doesn't have the idea of sendable types, ownership, read-only references, and so on.

For example, is the following program safe, or does it race?

    func processData(lines
The answer is of course that it's a data race. Why?

Because `buf.Bytes()` returns the underlying memory, and then `Reset` lets you re-use the same backing memory, and so "processData" and "main" are both writing to the same data at the same time.

In rust, this would not compile because it is two mutable references to the same data, you'd either have to send ownership across the channel, or send a copy.

In go, it's confusing. If you use `bytes.Buffer.ReadBytes("\n")` you get a copy back, so you can send it. Same for `bytes.Buffer.String()`.

But if you use `bytes.Buffer.Bytes()` you get something you can't pass across a channel safely, unless you also never use that bytes.Buffer again.

Channels in rust solve this problem because rust understands "sending" and ownership. Go does not have those things, and so they just give you a new tool to shoot yourself in the foot that is slower than mutexes, and based on my experience with new gophers, also more difficult to use correctly.

Re: There is no memory safety without thread safety

#98

Post by ameliaquining »

philosophty wrote: post #31
ameliaquining wrote: post #16

Earlier quoted context omitted.

What precisely are you accusing your interlocutor of not understanding?

Why people with vastly more skill and experience programming and writing programming languages made the decisions they did.

I meant, which particular design decisions are you accusing people of having failed to comprehend the rationale for?

Re: There is no memory safety without thread safety

#99

Post by amluto »

comex wrote: post #76
tptacek wrote: post #27

Earlier quoted context omitted.

There's enormous incentive to construct those exploits. Why don't they exist?

You’re a cryptography person. So you know that most theoretically interesting cryptography vulnerabilities, even the ones that are exploitable in PoCs, are too obscure and/or difficult to get used by actual attackers. Same goes for hardware vulnerabilities. Rowhammer and speculative execution attacks are often shown to be able to corrupt and leak memory, respectively, but AFAIK there are no famous cases of them actua…

> when was the last time you heard of a modern application backend being exploited through memory corruption, in any language?

It happens all the time, but it’s a bit hard to find because “modern application backend[s]” are usually written in Go or Python or Rust. Even so, you’ll find plenty of exploits based on getting a C or C++ library on the backend to parse a malformed file.

Re: There is no memory safety without thread safety

#100

Post by kstrauser »

Calavar wrote: post #94
kstrauser wrote: post #85

Earlier quoted context omitted.

I’d argue that unsafety is binary. If a normal eng doing normal things can break it without going out of their way to deliberately fool the compiler or runtime, I’d call it unsafe.

By that definition Rust also counts as unsafe. Even managed languages like C# and Java would be unsafe.

My impression of the Rust devs is that they’d agree with you about any easy-to-trigger calamities. So would Java contributors. C# might not because MS is institutionally not good about admitting mistakes, but I bet the individual devs would agree over a beer.
Post reply on HN