I agree with the sentiment. Consider a hypothetical variant of Python that requires using eval() (with the same behavior as in Python, so full Python expression

I agree with the sentiment. Consider a hypothetical variant of Python that requires using eval() (with the same behavior as in Python, so full Python expression support) for converting from strings to integers or floats. Or that implicitly calls eval() on list subscripts, to turn strings into integers. None of these changes impact memory safety, but it still makes it much more likely that common code has security vulnerabilities. (There is actually a widely used programming language with the eval-on-subscript feature …) > While a Go program may exhibit what a Rust or C++ program would consider undefined behavior, and it does also consider it an error, the consequences are very different. You don’t get time travel. You get 998 instead of 1,000. This isn't correct. Data races on multi-word objects of built-in type, such as slices and interfaces, actually have undefined behavior, in the sense that array bounds checking and type checking may break down. Russ Cox's old example still works if you disable optimizations: https://research.swtch.com/gorace https://research.swtch.com/gorace It looks like some form of dead store elimination happens to eliminate the data race with current compilers. For now, it's possible to bring it back by adding a pointless atomic operation, like this: go func(){ for !done { k = i atomic.AddUint32(&global, 1) k = j } }()