From 235551a9649050f1cb8135b46359c5d706b5605d Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 24 Jul 2025 20:01:41 +0200 Subject: [PATCH 1/1] link more directly to anecdotal evidence (albeit with less context) --- personal/_posts/2025-07-24-memory-safety.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md index 26a2427..c3ff4c6 100644 --- a/personal/_posts/2025-07-24-memory-safety.md +++ b/personal/_posts/2025-07-24-memory-safety.md @@ -100,7 +100,7 @@ This means it is, strictly speaking, not a memory safe language: the best the la 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://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). +and there is at least [anecdotal evidence of actual memory safety violations](https://www.reddit.com/r/rust/comments/wbejky/comment/iid990t). 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