mention Go concurrency expectations

diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md
index 3c1e48a7b279f0815a882e2cfd4bb53bc7991181..c12a125610f4a08b6a75121bb8585b2e826466a3 100644 (file)
--- a/personal/_posts/2025-07-24-memory-safety.md
+++ b/personal/_posts/2025-07-24-memory-safety.md
@@ -104,6 +104,7 @@ It is therefore not surprising that [data races are a huge problem in Go](https:
 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.
 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.
 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.
 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.
 
 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".
 I think that is a problematic blind spot.
 
 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".