X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/235551a9649050f1cb8135b46359c5d706b5605d..b5417c83c8f04e70e04c7c1fbf6cee6f3fb22419:/personal/_posts/2025-07-24-memory-safety.md?ds=sidebyside

diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md
index c3ff4c6..74fd1b0 100644
--- a/personal/_posts/2025-07-24-memory-safety.md
+++ b/personal/_posts/2025-07-24-memory-safety.md
@@ -100,14 +100,15 @@ 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/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.
+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).
 Even experienced Go programmers do not always realize that you can break memory safety without using any unsafe operations or exploiting any compiler or language bugs.
 Go is a language *designed* for concurrent programming, so people do not expect footguns of this sort.
 I think that is a problematic blind spot.
 
+Of course, as all things in language design, in the end this is a trade-off.
+Go made the simplest possible choice here, which is entirely in line with the general design of the language.
+There's nothing fundamentally wrong with that.
+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.
 The [Go memory model documentation](https://go.dev/ref/mem) is not exactly upfront about this point either: the "Informal Overview" emphasizes that "most races have a limited number of outcomes" and remarks that Go is unlike "C and C++, where the meaning of any program with a race is entirely undefined".
 You could say that the use of "most" here is foreshadowing, but this section does not list any cases where the number of outcomes is unlimited, so this is easy to miss.
 They even go so far as to claim that Go is "more like Java or JavaScript", which I think is rather unfair, given the lengths to which those languages went to achieve the thread safety they have.