From: Ralf Jung Date: Thu, 24 Jul 2025 15:19:12 +0000 (+0200) Subject: mention Go concurrency expectations X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/f2e0cb781b6f9b1de1abd6da079cd2022cc9104f?ds=sidebyside;hp=0c29fd73b78684e99915dd47718c5475ff197f09 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 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".