links for the Go folk's take on this, and wording improvements

diff --git a/personal/_posts/2025-07-24-memory-safety.md b/personal/_posts/2025-07-24-memory-safety.md
index 6d20f9e3a15eefcaea61537dc26420d608138f00..e05d0a3c0ef50caeb8881a6f1156575299adae75 100644 (file)
--- a/personal/_posts/2025-07-24-memory-safety.md
+++ b/personal/_posts/2025-07-24-memory-safety.md
@@ -108,7 +108,7 @@ Even experienced Go programmers do not always realize that you can break memory
 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.
 
 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.
+Of course, as all things in language design, in the end this is a trade-off and the Go folks are [well aware](https://research.swtch.com/gorace) of the problem.[^gosafe]

 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](https://www.memorysafety.org/docs/memory-safety/) as languages that actually *did* go through the effort of solving the problem with data races misrepresents the safety promises of the language.
 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](https://www.memorysafety.org/docs/memory-safety/) as languages that actually *did* go through the effort of solving the problem with data races misrepresents the safety promises of the language.


@@ -117,6 +117,8 @@ You could say that the use of "most" here is foreshadowing, but this section doe
 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.
 Only [a later subsection](https://go.dev/ref/mem#restrictions) explicitly admits to the fact that *some* races in Go *do* have entirely undefined behavior (which is very unlike Java or JavaScript).
 
 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.
 Only [a later subsection](https://go.dev/ref/mem#restrictions) explicitly admits to the fact that *some* races in Go *do* have entirely undefined behavior (which is very unlike Java or JavaScript).
 

+[^gosafe]: I tried to figure out whether the Go developers themselves consider their language to be memory safe, but was not able to reach a firm conclusion. The Go website does not take a stance on the matter. In [this 2009 talk](https://www.youtube.com/watch?v=rKnDgT73v8s&t=463s), Rob Pike says memory safety is a goal of Go, but in [this 2012 slide deck](https://go.dev/talks/2012/splash.slide#49) he calls the language "not purely memory safe" since "sharing is legal".
+

 ## Conclusion
 
 I would argue that the actual property people care about when talking about memory safety is that *the program cannot break the language*.
 ## Conclusion
 
 I would argue that the actual property people care about when talking about memory safety is that *the program cannot break the language*.


@@ -128,6 +130,7 @@ The moment your program has UB, all bets are off; whether or not an attacker can
 
 In my view, there's a bright line dividing "safe" languages where programs cannot have Undefined Behavior, and "unsafe" languages where they can.
 There's no meaningful sense in which this can be further subdivided into memory safety, thread safety, type safety, and whatnot -- it doesn't matter *why* your program has UB, what matters is that a program with UB defies the basic abstractions of the language itself, and this is a perfect breeding ground for vulnerabilities.
 
 In my view, there's a bright line dividing "safe" languages where programs cannot have Undefined Behavior, and "unsafe" languages where they can.
 There's no meaningful sense in which this can be further subdivided into memory safety, thread safety, type safety, and whatnot -- it doesn't matter *why* your program has UB, what matters is that a program with UB defies the basic abstractions of the language itself, and this is a perfect breeding ground for vulnerabilities.

+Therefore, we shouldn't call a language "memory safe" if the language does not systematically prevent Undefined Behavior.

 
 In practice, of course, safety is not binary, it is a spectrum, and on that spectrum Go is much closer to a typical safe language than to C.
 It is plausible that UB caused by data races is less useful for attackers than UB caused by direct out-of-bounds or use-after-free accesses.
 
 In practice, of course, safety is not binary, it is a spectrum, and on that spectrum Go is much closer to a typical safe language than to C.
 It is plausible that UB caused by data races is less useful for attackers than UB caused by direct out-of-bounds or use-after-free accesses.