There is no memory safety without thread safety

Post by comex » Thu, Jul 24, 2025, 8:06 PM UTC

amluto wrote: post #99

comex wrote: post #76

Earlier quoted context omitted.

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.

Post by pjmlp » Thu, Jul 24, 2025, 8:17 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?

Post by pjmlp » Thu, Jul 24, 2025, 8:26 PM UTC

9rx wrote: post #124

Yoric wrote: post #104

Earlier quoted context omitted.

Well, that and the slight fact that it bears Google's brand name. I personally appreciate Go as a research experiment. Plenty of very interesting ideas, just as, for instance, Haskell. I don't particularly like it as a development language, but I can understand why some people do.

> Plenty of very interesting ideas Is there? When you get down to it, it is really just a faster Python. Which is exactly what it was said to be when it was released. Their goal was to create a "dynamically-typed" language that was more performant. It is likely that it wouldn't have had a static type system at all if they figured out how to achieve on the performance end without needing types. You can tell who is clu…

Post by tptacek » Thu, Jul 24, 2025, 8:28 PM UTC

qualeed wrote: post #32

tptacek wrote: post #27

Earlier quoted context omitted.

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

This seems to be operating on the premise that everyone knows of every exploit that exists. There's also an enormous incentive to hide working exploits.

Post by devnullbrain » Thu, Jul 24, 2025, 8:47 PM UTC

norir wrote: post #58

bombela wrote: post #23

Earlier quoted context omitted.

It took months to finally solve a data race in Go. No race detector would see anything. Nobody understood what was happening. It ultimately resulted in a loop counter overflowing, which recomputed the same thing a billion of time (but always the same!). So the visible effect was a request would randomly take 3 min instead of 100ms. I ended up using perf in production, which indirectly lead me to understand the data r…

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…