There is no memory safety without thread safety • Hacker News Board

Re: There is no memory safety without thread safety

#331

Post by layer8 » Fri, Jul 25, 2025, 10:27 AM UTC

nine_k wrote: post #233

potato-peeler wrote: post #136

Earlier quoted context omitted.

I am curious. Generally basic structures like map are not thread safe and care has to be taken while modifying it. This is pretty well documented in go spec. In your case in dropbox, what was essentially going on?

In Java, there are separate synchronized collections, because acquiring a lock takes time. Normally one uses thread-unsafe collections. Java also gives a very ergonomic way to run any fragment under a lock (the `synchronized` operator). Rust avoids all this entirely, by using its type system.

Java has separate synchronized collections only because that was initially the default, until people realized that it doesn’t help for the common cases of check-and-modify operations or of having consistency invariants with state outside a single collections (besides the performance impact). In practice, synchronized collections are rarely useful, and instead accesses are synchronized externally.

Re: There is no memory safety without thread safety

#332

Post by SkiFire13 » Fri, Jul 25, 2025, 10:31 AM UTC

pizlonator wrote: post #263

dwattttt wrote: post #232

Earlier quoted context omitted.

> 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. By these definitions, doesn't that mean go is neither memory or thread safe? It looks like concurrent modification can result in memory corruption, e.g. the attempted access 0x42 example in the article

> By these definitions, doesn't that mean go is neither memory or thread safe? Yes, with the caveat that you can't treat "memory safe" as a binary condition. The strictest notion of memory safety is what I call GIMSO: "Garbage In, Memory Safety Out". I.e. there does not exist any sequence of bytes you could feed to the compiler that would result in a memory-unsafe outcome at runtime. Java aims for this. Fil-C does to…

In my opinion this is missing a very important different between the two approaches: using `unsafe`/`sun.misc.Unsafe` in Rust/C#/Java is a very deliberate choice which presence can easily be checked syntactically, meanwhile data races in Go are most often unintended and you can't easily check for their _guaranteed_ absence. Otherwise C/C++ are also "GIMSO" with the caveat "don't UB"!

Re: There is no memory safety without thread safety

#333

Post by goodpoint » Fri, Jul 25, 2025, 10:32 AM UTC

> safety is not binary, it is a spectrum, and on that spectrum Go is much closer to a typical safe language than to C

That's a too low bar to clear to call it safe.

Re: There is no memory safety without thread safety

#334

Post by samus » Fri, Jul 25, 2025, 10:40 AM UTC

nicoburns wrote: post #324

tptacek wrote: post #245

Earlier quoted context omitted.

It's a contrived type confusion bug. It reads 42h because that address is hardcoded, and it does something that ordinary code doesn't do. If you were engaged to do a software security assessment for an established firm that used Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), and you said "this code is memory-unsafe", showing them this exam…

You are however replying to thread where a Dropbox engineer calls it "a right of passage" to introduce such bugs to their codebase. Which suggests that it is by no means unheard of for these problems to crop up in real-world code.

Doesn't Dropbox write a lot of Python extensions in C for speedup?

Re: There is no memory safety without thread safety

#335

Post by blub » Fri, Jul 25, 2025, 10:40 AM UTC

tptacek wrote: post #168

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…

Right, the issue here is that the "Rust and Java sense" of memory safety is not the actual meaning of the term. People talk as if "memory safety" was a PLT axiom. It's not; it's a software security term of art. This is just two groups of people talking past each other. It's not as if Go programmers are unaware of the distinction you're talking about. It's literally the premise of the language; it's the basis for "sha…

The problem Rust has is that it’s not enough to be memory safe, because lots of languages are memory safe and have been for decades.

Hence the focus on fearless concurrency or other small-scale idioms like match in an attempt to present Rust as an overall better language compared to other safe languages like Go, which is proving to be a solid competitor and is much easier to learn and understand.

Re: There is no memory safety without thread safety

#336

Post by layer8 » Fri, Jul 25, 2025, 10:42 AM UTC

qcnguy wrote: post #24

The point being made is sound, but I can never escape the feeling that most concurrency discussion in programming language theory is ignoring the elephant in the room. The concurrency bugs that matter in most apps are all happening inside the database due to lack of proper locking, transactions or transactional isolation. PL theory ignores this and so things like Rust's approach to race freedom ends up not mattering…

What’s worse, even if you use proper transactions for everything, it’s hard to reason about visibility and data races when performing SQL across tables, or multiple dependent SQL statements within a transaction.

Re: There is no memory safety without thread safety

#337

Post by blub » Fri, Jul 25, 2025, 10:43 AM UTC

nicoburns wrote: post #324

tptacek wrote: post #245

Earlier quoted context omitted.

It's a contrived type confusion bug. It reads 42h because that address is hardcoded, and it does something that ordinary code doesn't do. If you were engaged to do a software security assessment for an established firm that used Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), and you said "this code is memory-unsafe", showing them this exam…

You are however replying to thread where a Dropbox engineer calls it "a right of passage" to introduce such bugs to their codebase. Which suggests that it is by no means unheard of for these problems to crop up in real-world code.

Many FAANG & co engineers are overrated. If every new hire is introducing concurrency bugs in a Golang codebase, refactor, do better review and maybe use concurrency questions instead of leetcode.

I’ll take tptacek’s word over most FAANG type on such topics if we’re doing appeals to authority. The guy is very practical, unlike the Rust community which is incredibly focused on theoretical correctness instead of real-world experiences.

Re: There is no memory safety without thread safety

#338

Post by layer8 » Fri, Jul 25, 2025, 10:46 AM UTC

swiftcoder wrote: post #298

I wish we had picked a better name than "thread safety". This is really more like "concurrency safety", since it applies even in the absence of hardware threads.

Threads aren’t hardware, they are OS. Multihreading != multiprocessing.

Re: There is no memory safety without thread safety

#339

Post by zozbot234 » Fri, Jul 25, 2025, 10:49 AM UTC

blub wrote: post #335

tptacek wrote: post #168

Earlier quoted context omitted.

Right, the issue here is that the "Rust and Java sense" of memory safety is not the actual meaning of the term. People talk as if "memory safety" was a PLT axiom. It's not; it's a software security term of art. This is just two groups of people talking past each other. It's not as if Go programmers are unaware of the distinction you're talking about. It's literally the premise of the language; it's the basis for "sha…

The problem Rust has is that it’s not enough to be memory safe, because lots of languages are memory safe and have been for decades. Hence the focus on fearless concurrency or other small-scale idioms like match in an attempt to present Rust as an overall better language compared to other safe languages like Go, which is proving to be a solid competitor and is much easier to learn and understand.

Except that Swift also has safe concurrency now. It's not just Rust. Golang is actually a very nice language for problems where you're inherently dependent on high-performance GC and concurrency, so there's no need to present it as "better" for everything. Nevertheless its concurrency model is far from foolproof when compared to e.g. Swift.

Re: There is no memory safety without thread safety

#340

Post by zozbot234 » Fri, Jul 25, 2025, 10:50 AM UTC

layer8 wrote: post #338

swiftcoder wrote: post #298

I wish we had picked a better name than "thread safety". This is really more like "concurrency safety", since it applies even in the absence of hardware threads.

Threads aren’t hardware, they are OS. Multihreading != multiprocessing.

Hardware threads are a thing.