From: Ralf Jung Date: Thu, 24 Jul 2025 15:53:31 +0000 (+0200) Subject: link to dtolnay's discussion of the issue X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/3e019d0e5ed525050b953b4c881631d3984e99ae?ds=inline;hp=4a2c7e8d896f626c7c83488fcb06d59845f378df link to dtolnay's discussion of the issue --- 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.