link more directly to anecdotal evidence (albeit with less context)

diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md
index 26a2427754f44102766a41798208992c6c62424b..c3ff4c603e0215caeb3ae70bf185f7240c069961 100644 (file)
--- 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.