]> git.ralfj.de Git - web.git/commitdiff
better reddit link
authorRalf Jung <post@ralfj.de>
Fri, 25 Jul 2025 07:43:10 +0000 (09:43 +0200)
committerRalf Jung <post@ralfj.de>
Fri, 25 Jul 2025 07:43:10 +0000 (09:43 +0200)
personal/_posts/2025-07-24-memory-safety.md

index c3ff4c603e0215caeb3ae70bf185f7240c069961..9504283657c5267db39091c338094665205a3982 100644 (file)
@@ -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),
 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/iid990t).
+and there is at least [anecdotal evidence of actual memory safety violations](https://old.reddit.com/r/rust/comments/wbejky/a_succinct_comparison_of_memory_safety_in_rust_c/iid990t/?context=2).
 
 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.
 
 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.