From f2e0cb781b6f9b1de1abd6da079cd2022cc9104f Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 24 Jul 2025 17:19:12 +0200 Subject: [PATCH] mention Go concurrency expectations --- personal/_posts/2025-07-24-memory-safety.md | 1 + 1 file changed, 1 insertion(+) diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md index 3c1e48a..c12a125 100644 --- 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. +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". -- 2.39.5