"at the moment" implies that Go would need to change for that statement to change, but instead we're waiting on a programer to make a mistake (A mistake that memory safe languages prevent).
Which does get us to why defining the properties of a language based on what people have written in that language _so far_ is weird. It's not really a property of the language that no one has screwed up yet. It's perhaps an indication that it might be less likely that folks will screw up, which is where the "probabilistic" comes in. It assumes that given the lack of a counter example (a screw up) so far, and given the time that Go has existed, it _appears_ that it's low-likelyhood to screw up go programs in that particular way.
Agreed that the word is non-targeted in one way, but it's better than the alternate (implying go would have to change to become memory unsafe), if one wants to talk about how-memory-safe-is-go.
> "at the moment" implies that Go would need to change for that statement to change
I agree that "at the moment" could imply that Go would need to change for that statement to change, but I think it could also imply that "effectively/practically" could change as well since "effectively/practically" in this context implies a particular state of knowledge about known exploits (i.e., that there are none). If someone releases a practical data race exploit for real-world Go codebases tomorrow, "effectively/practically" would no longer hold, and therefore the statement would no longer hold despite Go not changing. The representation of the state of knowledge is part of why I suggested the lawyer-y version :P
Which does get us to why defining the properties of a language based on what people have written in that language _so far_ is weird. It's not really a property of the language that no one has screwed up yet. It's perhaps an indication that it might be less likely that folks will screw up, which is where the "probabilistic" comes in. It assumes that given the lack of a counter example (a screw up) so far, and given the time that Go has existed, it _appears_ that it's low-likelyhood to screw up go programs in that particular way.
Agreed that the word is non-targeted in one way, but it's better than the alternate (implying go would have to change to become memory unsafe), if one wants to talk about how-memory-safe-is-go.