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

Re: There is no memory safety without thread safety

#161

Post by tomp » Thu, Jul 24, 2025, 7:33 PM UTC

recursivecaveat wrote: post #119

norir wrote: post #58

Earlier quoted context omitted.

It is very unfortunate that we use fixed width numbers by default in most programming languages and that common ops will silently overflow. Smarter compilers can work with richer numeric primitives and either automatically promote machine words to big numbers or throw an error on overflow. People talk a lot about the productivity gains of ai, but fixing problems like this at the language level could have an even bigg…

The situation with numbers in basically every widely used programming language is kind of an indictment of our industry. Silent overflow for incorrect results, no convenient facilities for units, lossy casts everywhere. It's one of those things where standing in 1975 you'd think surely we'll spend some of the next 40 years of performance gains to give ourselves nice, correct numbers to work with, but we never did.

"nice, correct numbers" end somewhere between 1/3 and sqrt(2)

so in reality, it's just "pick your own poison" to various degrees...

Re: There is no memory safety without thread safety

#162

Post by tptacek » Thu, Jul 24, 2025, 7:34 PM UTC

jstarks wrote: post #64

tptacek wrote: post #4

This is a canard. What's happening here, as happens so often in other situations, is that a term of art was created to describe something complicated; in this case, "memory safety", to describe the property of programming languages that don't admit to memory corruption vulnerabilities, such as stack and heap overflows, use-after-frees, and type confusions. Later, people uninvolved with the popularization of the term…

> If you want to claim that a language is memory-unsafe, POC || GTFO. There's a POC right in the post, demonstrating type confusion due to a torn read of a fat pointer. I think it could have just as easily been an out-of-bounds write via a torn read of a slice. I don't see how you can seriously call this memory safe, even by a conservative definition. Did you mean POC against a real program? Is that your bar?

You need a non-contrived example of a memory-corrupting data race that gives attackers the ability to control memory, through type confusion or a memory lifecycle bug or something like it. You don't have to write the exploit but you have to be able to tell the story of how the exploit would actually work --- "I ran this code and it segfaulted" is not enough. It isn't even enough for C code!

Re: There is no memory safety without thread safety

#163

Post by wmf » Thu, Jul 24, 2025, 7:34 PM UTC

qcnguy wrote: post #26

jchw wrote: post #2

This comes up now and again, somewhat akin to the Rust soundness hole issue. To be fair, it is a legitimate issue, and you could definitely cause it by accident, which is more than I can say about the Rust soundness hole(s?), which as far as I know are basically incomprehensible and about as likely to come across naturally as guessing someone's private key. That said in many years of using Go in production I don't th…

What do Uber mean in that article when they say that Go programs "expose 8x more concurrency compared to Java microservices"? They're using the word concurrency as if it were a countable noun.

If the Java version creates 4 concurrent tasks (could be threads, fibers, futures, etc.) but the Go version creates 32 goroutines, that's 8x the concurrency.

Re: There is no memory safety without thread safety

#164

Post by [deleted] » Thu, Jul 24, 2025, 7:35 PM UTC

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…

[deleted]

Re: There is no memory safety without thread safety

#165

Post by tialaramex » Thu, Jul 24, 2025, 7:36 PM UTC

nine_k wrote: post #131

tialaramex wrote: post #113

Earlier quoted context omitted.

Originally Rust is something altogether different. Graydon has written about that extensively. Graydon wanted tail calls, reflection, more "natural" arithmetic with Python style automatic big numbers, decimal for financial work and so on. The Rust we have from 1.0 onwards is not what Graydon wanted at all. Would Graydon's language have been broadly popular? Probably not, we'll never know.

While at it, I suppose it's straightforward to implement arbitrary-precision integers and decimals in today's Rust; there are several crates for that. There's also a `tailcall` crate that apparently implements TCO [1]. [1]: https://docs.rs/tailcall/latest/tailcall/

Oh, I do know you can have arbitrary precision. I'm the author of realistic, which isn't "just" arbitrary precision it's an approximation of the computable reals as well, which is sometimes just enough more power than you'd hardly notice you have arbitrary precision too.

https://crates.io/crates/realistic

Re: There is no memory safety without thread safety

#166

Post by LtWorf » Thu, Jul 24, 2025, 7:38 PM UTC

adamwk wrote: post #142

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…

Crashing on shared access is the safe thing to do

a segfault is completely unintentional. Had the kernel been older it could be used to execute code.

Re: There is no memory safety without thread safety

#167

Post by tptacek » Thu, Jul 24, 2025, 7:39 PM UTC

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…

There's lots of clientside Go, too!

Re: There is no memory safety without thread safety

#168

Post by tptacek » Thu, Jul 24, 2025, 7:40 PM UTC

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 "share by communicating, don't communicate by sharing". Obviously, that didn't work out, and modern Go does a lot of sharing and needs a lot of synchronization. But: everybody understands that.

Re: There is no memory safety without thread safety

#169

Post by LtWorf » Thu, Jul 24, 2025, 7:41 PM UTC

the_plus_one wrote: post #141

pjmlp wrote: post #93

Earlier quoted context omitted.

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

> or too young to remember former languages. Do you have any good examples? Not trying to argue, just genuinely curious as someone who hasn't been in this field for decades.

Basically go was designed ignoring all the research and progress that had been made in programming languages until then.

It was designed with contempt for developers, for example disallowing developers to create generic data structures, or lacking a decent way of error checking that is not extremely error prone and verbose.

Re: There is no memory safety without thread safety

#170

Post by 9rx » Thu, Jul 24, 2025, 7:41 PM UTC

Animats wrote: post #122

pjmlp wrote: post #102

Earlier quoted context omitted.

The only reason it didn't end on pile of obscure languages nobody uses, it called Google, followed by luck with Docker and Kubernetes adoption on the market, after they decided to rewrite from Python and Java respectively into Go, after Go heads joined their teams. Case in point, Limbo and Oberon-2, the languages that influenced its design, and authors were involved with.

The strength of Go is not the language. It's that the libraries you need for web back-end stuff are written, maintained, and used in production by Google. All the obscure cases get exercised in production due to sheer volume of internal usage. At one time, Go maps were not thread-safe. Was that fixed?

> At one time, Go maps were not thread-safe. Was that fixed?

sync.Map was added, but isn't intended to be a general purpose map.

——

The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content.

The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.