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

201–210 of 517 posts

Re: There is no memory safety without thread safety

#201

Post by dwattttt »

pizlonator wrote: post #196
glowcoil wrote: post #179

Earlier quoted context omitted.

I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: > At this point you might be wondering, isn’t this a problem in many languages? Doesn’t Java also allow data races? And yes, Java does allow data races, but the Java developers spent a lot of effort to ensure that even programs with data races remain entirely well-…

> I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: The title is wrong. That's important. > Java is in fact thread-safe in the sense of the term used in the article The article's notion of thread safety is wrong. Java is not thread safe by construction, but it is memory safe.

If a language is "memory safe", by some definition we expect safety from memory faults (for example, not accessing memory incorrectly).

If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"?

Or to put it another way; when used however the term of art is intended, "memory safety" is meant to provide some guarantees about not triggering certain erroneous conditions. "not thread safe" seems to mean that those same erroneous conditions can be triggered by threads, which seems to amount to '"memory safety" does not guarantee the absence of erroneous memory conditions'.

Re: There is no memory safety without thread safety

#202

Post by littlestymaar »

fmajid wrote: post #200
kibwen wrote: post #156

Earlier quoted context omitted.

Even in pre-1.0 Rust, concurrency was a primary goal; there's a reason that Graydon listed Newsqueak, Alef, Limbo, and Erlang in the long list of influences for proto-Rust.

And yet it ignored the primary lesson of Erlang: no shared memory access whatsoever, which is what makes it so robust.

Because the other teams members (IIRC brson and pcwalton) wanted Rust to be as performant as C++, which means you must have a way to have shared memory.

Re: There is no memory safety without thread safety

#203

Post by gf000 »

ameliaquining wrote: post #148
gf000 wrote: post #35

Earlier quoted context omitted.

Hide the same program into some dependency of a dependency and you have a nice little security vulnerability in your prod app. It's actually very easy to hide such a vulnerability as an innocent bug.

If you're stipulating deliberately inserted vulnerabilities then there are much easier ways, e.g., with a plausibly-deniable logic bug in code that calls os/exec or reflect (both of which can execute arbitrary code by design).

If you see `exec`, that's an obvious point where you want to pay extra attention.

Compare to an innocent looking map operation, and it's not even in the same league.

Re: There is no memory safety without thread safety

#204

Post by dwattttt »

dwattttt wrote: post #201
pizlonator wrote: post #196

Earlier quoted context omitted.

> I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: The title is wrong. That's important. > Java is in fact thread-safe in the sense of the term used in the article The article's notion of thread safety is wrong. Java is not thread safe by construction, but it is memory safe.

If a language is "memory safe", by some definition we expect safety from memory faults (for example, not accessing memory incorrectly). If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Or to put it another way; when used however the term of art is intended, "memory safety" is meant to provide some guarantees about not trigger…

I guess to also elaborate the point; it's also entirely correct to say "Rust is guaranteed to be memory safe unless 'unsafe' is involved".

Re: There is no memory safety without thread safety

#205

Post by Thaxll »

Sesse__ wrote: post #108
Thaxll wrote: post #92

Earlier quoted context omitted.

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.

https://en.wikipedia.org/wiki/Argument_from_authority

So NSA does not have the relevant authority to qualify a language as memory safe, is it what you're saying?

The document is backed by foreign government as well.

https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE...

Re: There is no memory safety without thread safety

#206

Post by pizlonator »

dwattttt wrote: post #201
pizlonator wrote: post #196

Earlier quoted context omitted.

> I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: The title is wrong. That's important. > Java is in fact thread-safe in the sense of the term used in the article The article's notion of thread safety is wrong. Java is not thread safe by construction, but it is memory safe.

If a language is "memory safe", by some definition we expect safety from memory faults (for example, not accessing memory incorrectly). If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Or to put it another way; when used however the term of art is intended, "memory safety" is meant to provide some guarantees about not trigger…

> If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"?

Yes.

If a language is memory safe but not thread safe, then you can race, but the outcome of those races won't be memory corruption or the violation of the language's type system. It will lead to weird stuff, however - just a different kind of weirdness than breaking out of the language's sandbox

Re: There is no memory safety without thread safety

#207

Post by pizlonator »

dwattttt wrote: post #204
dwattttt wrote: post #201

Earlier quoted context omitted.

If a language is "memory safe", by some definition we expect safety from memory faults (for example, not accessing memory incorrectly). If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Or to put it another way; when used however the term of art is intended, "memory safety" is meant to provide some guarantees about not trigger…

I guess to also elaborate the point; it's also entirely correct to say "Rust is guaranteed to be memory safe unless 'unsafe' is involved".

Yeah and Rust is guaranteed to be thread safe unless 'unsafe' is involved, I think

Re: There is no memory safety without thread safety

#208

Post by philosophty »

henry700 wrote: post #67
philosophty wrote: post #31

Earlier quoted context omitted.

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

Skill? Go? With the amount of mistakes piling up over the years comparable to PHP at this point? Really??

These guys have each forgotten 10x than you know about programming.

https://swtch.com/~rsc/

https://en.wikipedia.org/wiki/Ken_Thompson

https://en.wikipedia.org/wiki/Robert_Griesemer

https://en.wikipedia.org/wiki/Rob_Pike

Re: There is no memory safety without thread safety

#209

Post by philosophty »

mrkeen wrote: post #110
philosophty wrote: post #31

Earlier quoted context omitted.

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

The only decisions that matter for languages that get adopted are the decisions that cause adoption. JS went without static types, Go went without generics, PHP was just a tool for reducing html boilerplate. New languages love to stick null right in there. Rust isn't what Graydon Hoare wanted it to be. Chris Lattner called Swift a failure. It's all up for criticism.

Sure, there are valid criticisms of anything but without understanding they're unlikely to be useful or correct.

Re: There is no memory safety without thread safety

#210

Post by [deleted] »

ameliaquining wrote: post #98
philosophty wrote: post #31

Earlier quoted context omitted.

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?

[deleted]
Post reply on HN