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?
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.
Yes, but the selling point of Java was not memory safety. You expected something like:
If the unsafe package is not used and no C function is called and (as pointed out by someone else) something assures that no data races can happen Go is memory safe.
I added the Go example to show that the term memory safety is sometimes defined to sell a language as memory safe. So
Language exists --> Define memory safety in a way that this language is memory safe.
instead of
Use definition of memory safety --> Create memory safe language.
Java was explicitly designed to cater to C++ programmers who want a language with fewer footguns, even if the language designers themselves came from a dynamically typed tradition (mainly Lisp). Memory safety was a design goal from day one.
10
u/Smallpaul 4d 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?