From 3e019d0e5ed525050b953b4c881631d3984e99ae Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 24 Jul 2025 17:53:31 +0200 Subject: [PATCH] link to dtolnay's discussion of the issue --- personal/_posts/2025-07-24-memory-safety.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md index 6c4c7f6..45bdc32 100644 --- a/personal/_posts/2025-07-24-memory-safety.md +++ b/personal/_posts/2025-07-24-memory-safety.md @@ -99,7 +99,8 @@ Go, unfortunately, chose to do neither of these. This means it is, strictly speaking, not a memory safe language: the best the language can promise is that *if* a program has no data races (or more specifically, no data races on problematic values such as interfaces, slices, and maps), then its memory accesses will never go wrong. Now, to be fair, Go comes with out-of-the-box tooling to detect data races, which quickly finds the issue in my example. However, in a real program, that means you have to hope that your test suite covers all the situations your program might encounter in practice, which is *exactly* the sort of issue that a strong type system and static safety guarantees are intended to avoid. -It is therefore not surprising that [data races are a huge problem in Go](https://dl.acm.org/doi/pdf/10.1145/3519939.3523720). +It is therefore not surprising that [data races are a huge problem in Go](https://arxiv.org/pdf/2204.00764), +and there is at least [anecdotal evidence of actual memory safety violations](https://www.reddit.com/r/rust/comments/wbejky/comment/ii9piqe). I could accept Go's choice as an engineering trade-off, aimed at keeping the language simpler. However, putting Go into the same bucket as languages that actually *did* go through the effort of solving the problem with data races misrepresents the safety promises of the language. -- 2.39.5