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

391–400 of 517 posts

Re: There is no memory safety without thread safety

#391

Post by pjmlp »

ardit33 wrote: post #275
junebash wrote: post #71

Earlier quoted context omitted.

Swift is in the process of fixing this, but it’s a slow and painful transition; there’s an awful lot of unsafe code in the wild that wasn’t unsafe until recently.

It is still incomplete and a mess. I don't think they thought through the actual main cases Swift is used for (ios apps), and built a hypothetical generic way which is failing on most clients. Hence lots of workarounds, and ways to get around it (The actor system). The isolated/nonisolated types are a bit contrived and causing real productivity loss, when the old way was really just 'everything ui in main thread, eve…

Their goal was always to be able to evolve to the point of being able fully replace C, Objective-C and C++ with Swift, it has been on their documentation and plenty of WWDC sessions since the early days.

Re: There is no memory safety without thread safety

#392

Post by ngrilly »

ralfj wrote: post #364
ngrilly wrote: post #310

Earlier quoted context omitted.

The terms correctness (from a PLT perspective) and safety (from a security perspective) are not equivalent and interchangeable. I see them mixed up too much in this discussion.

PLT has used the term "type safety" for a very long time -- so "safety" does not imply a security perspective. And yes it is indeed very different from correctness. But the article doesn't claim that memory safety should imply correctness -- that would be ridiculous, obviously you can write buggy programs in memory-safe languages. The article claims that Go is not memory-safe.

I was referring to comments mentioning correctness and safety as interchangeable terms. The article doesn’t mix them up.

Re: There is no memory safety without thread safety

#393

Post by ralfj »

tptacek wrote: post #372
ralfj wrote: post #370

Earlier quoted context omitted.

Yeah I understand that that's how you like to use the term, you've been very clear about that. What I am curious about is whether that's just you. Because the source you gave last time, https://www.memorysafety.org/docs/memory-safety/ , doesn't agree with what you are saying, and neither does Wikipedia. I am honestly curious here. I am a PLT researcher so I am in a bubble where people use the term consistently with h…

Again: my usage of the term is widespread enough that the ISRG uses it to refer to Go as well, as does, well, basically everybody else in the industry. I think you've just message-boarded yourself into believing this is a live debate. There is no sequence of words you're going to come up with to convince me that everybody is wrong when they say "Go is a memory safe language".

You keep making arguments by assertion without giving sources, so :shrug: yeah this isn't going to go anywhere.

I think we actually agree on all of the factual points here, we just don't agree on how languages should be categorized/labeled according to their guarantees in both a theoretical and a practical sense, and that's largely a subjective matter anyway. So, happy to agree to disagree here.

Re: There is no memory safety without thread safety

#394

Post by ralfj »

Thaxll wrote: post #382
ralfj wrote: post #370

Earlier quoted context omitted.

Yeah I understand that that's how you like to use the term, you've been very clear about that. What I am curious about is whether that's just you. Because the source you gave last time, https://www.memorysafety.org/docs/memory-safety/ , doesn't agree with what you are saying, and neither does Wikipedia. I am honestly curious here. I am a PLT researcher so I am in a bubble where people use the term consistently with h…

Go is memory safe, what do you think of: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... U.S. and International Partners Issue Recommendations to Secure Software Products Through Memory Safety They recommand Go among other language in their paper. https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE...

Yeah, Go is often listed with memory-safe languages, I know that. And yet when people define memory safety, Go usually fails to satisfy that definition. That's why I was asking for a definition of memory safety that would include Go.

Re: There is no memory safety without thread safety

#395

Post by 9rx »

pjmlp wrote: post #279
9rx wrote: post #188

Earlier quoted context omitted.

> Had Chrome team kept pushing DartVM, it might have been quite different story. Trouble with that line of thinking is that Google never pushed Go either. It didn't even bother to use it internally (outside from the occasional side project here and there). Google paid some salaries. I'll give you that. But it has paid salaries for a lot of different languages. That is not some kind of secret sauce. > It is officially…

I guess Kubernetes doesn't count as Google pushing it then. It is officially "not ready to use", it isn't a strawman as people keep complaining about nothing.

Kubernetes is written in Go (-ish. More like written in Java using Go syntax, especially in its early days when you claim it did some kind of pushing). But what kind of push are you dreaming up that it offered? If anything, Kubernetes leaves you to question if you ever want to write software again. The idea that it made anyone, let alone legions of people required to make something a "success", think "This is great. I should write my program in Go too!" is laughable.

Re: There is no memory safety without thread safety

#396

Post by Sharlin »

tptacek wrote: post #160
sophacles wrote: post #105

Earlier quoted context omitted.

I think your security background is coloring your perception of the term memory safety. Specifically the requirement that the various issues lead to exploitation. These issues can lead to many other issues that are not vulnerability in the security sense, e.g. data corruption, incorrect (but not insecure) behavior, performance issues, and more. I don't think any of those were ever dismissed or excluded from memory sa…

"Memory safety" is a security term, not a PLT term.

First off, in any and every engineering discipline it would be absurd to claim that "safety" only means security against intentional malice.

Second, the burden of proof goes the other way. It’s absurd to claim that UB is safe unless proven otherwise. Unsafety must obviously be the default assumption.

Re: There is no memory safety without thread safety

#397

Post by ralfj »

phire wrote: post #255
codys wrote: post #249

Curiously, Go itself is unclear about its memory safety on go.dev. It has a few references to memory safety in the FAQ ( https://go.dev/doc/faq#Do_Go_programs_link_with_Cpp_programs , https://go.dev/doc/faq#unions ) implying that Go is memory safe, but never defines what those FAQ questions mean with their statements about "memory safety". There is a 2012 presentation by Rob Pike ( https://go.dev/talks/2012/splash.sl…

The definition kind of changed. At the time Go was created, it met one common definition of "memory safety", which was essentially "have a garbage collector". And compared to c/c++, it is much safer.

> it met one common definition of "memory safety", which was essentially "have a garbage collector"

This is the first time I hear that being suggested as ever having been the definition of memory safety. Do you have a source for this?

Given that except for Go every single language gets this right (to my knowledge), I am kind of doubtful that this is a consequence of the term changing its meaning.

Re: There is no memory safety without thread safety

#398

Post by commandersaki »

Thaxll wrote: post #386
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…

I have a hard time believing that it's common to create SEGFAULT in Go, I worked with the language for a very long time and don't remember a single time where I've seen that. ( and i've seen many data race ) Not synchronizing writes on most data structure does not create a SEGFAULT, you have to be in a very specific condition to create one, those conditions are extremely rares and un-usual ( from the programmer persp…

You really have to go hunting for a segfault in Go. The critical sentence in OP article is: in practice, of course, safety is not binary, it is a spectrum, and on that spectrum Go is much closer to a typical safe language than to C. OP just has a vested interest in proving safety of languages and is making a big deal where in practice there is none. People are not making loads of unsafe programs in Go nor deploying as such because it would be pretty quickly detected. This is much different to C and C++.

Re: There is no memory safety without thread safety

#399

Post by uecker »

zozbot234 wrote: post #353
uecker wrote: post #352

Earlier quoted context omitted.

How granular the memory protection mechanism is is part of the implementation.

It's part of the broader system, not the language implementation. And in practice, systems that achieve this are not in common use.

You are using a narrower definition than me. The language implementation builds on the functionality of the a larger system. An implementation can utilize the functionality of the overall system and close the loopholes. For example, using sanitizer you can turn out-of-bounds accesses to arrays into traps. This is not a segmentation fault but SIGILL, but it also builds on the trapping mechanism to achieve bounds safety (if you limit yourself to arrays).

Re: There is no memory safety without thread safety

#400

Post by pizlonator »

ralfj wrote: post #385
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.

Java also sometimes uses "memory safe" to refer to programs that don't have null pointer exceptions. So in that sense, Java isn't memory safe by construction either. These terms are used slightly differently by different communities, which is why I discuss this point in the article. But you seem adamant that you have the sole authority for defining these terms so :shrug:

When those US government articles about how we should switch to memory safe languages come out, they refer to Java as a “memory safe language”.

They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages).

So no, I’m not an authority. I’m just following the general trend of how the term is used.

And ive never heard “memory safe” used in relation to not having null pointer exceptions. That’s a new one and sounds nonsensical, frankly

Post reply on HN