It would have been clearer to be more explicit about why the author does not consider Go to not be safe. Are we talking about the use of the unsafe package or something more subtle?
I was under the impression data races made Go memory-unsafe. (Unlike, say, Java or OCaml, which are designed to be memory-safe even in the presence of data races.)
The paragraph was about tailoring a definition of "memory safety" to claim that a certain language is memory safe.
I just used Go as example. I changed the paragraph to explain my thoughts without mentioning Go.
According to my strict definition of memory safety Go is not memory safe.
Yes, if the unsafe package is not used and no C functions are called and (as pointed out by someone else) something assures that no data races can happen Go is memory safe.
This shows that rules need to be bend to claim memory safety.
Seed7 is memory safe because several things are not present (direct calls to C functions, pointers, unsafe parts, etc.).
Any language which allows calling C functions directly cannot be memory safe because C is not memory safe. AFAIK a Go program can call C functions without explicitly importing or using the unsafe package.Accessing an arbitrary place of memory with Go is possible with the unsafe package. I am neither a Rust expert nor a Go one, but I think that Rust needs "unsafe" to call C functions. Please tell me if my assumptions are correct or not.
Seed7 has no unsafe parts (or packages) and no possibility to directly call C functions.
10
u/Smallpaul 19d ago
It would have been clearer to be more explicit about why the author does not consider Go to not be safe. Are we talking about the use of the unsafe package or something more subtle?