Comment by consteval

Comment by consteval 9 days ago

4 replies

I don't think that's ordinary code. In any language, if you don't use a thread safe container and mutate it from multiple threads you'll get problems. This isn't an issue of memory safety but rather thread safety. You have to check the documentation for thread safe operations or otherwise use a lock. This goes for C#, Java, Go, you name it - the one singular exception being Rust. But, even Rust does not fully get around it.

kccqzy 9 days ago

You missed the point.

> In any language, if you don't use a thread safe container and mutate it from multiple threads you'll get problems.

Yes I agree there will be problems but what kind of problems do you get? Can you potentially get a memory safety problem, or are you guaranteed that the problem is not a memory safety problem?

The point is that thread safety problems in Go lead to memory safety problems. That's not the case in Java. You can crash the whole Go program by doing that, but you cannot crash the JVM by doing the same thing.

  • yawaramin 9 days ago

    Crashing the whole program is actually memory safety. Because then the program can't get into an undefined state where parts of the program have access to memory they shouldn't.

    • kccqzy 9 days ago

      Crashing via SIGSEGV is not memory safety.

      • consteval 8 days ago

        Crashing with SIGSEGV can be perfectly memory safe. For example, writing to a NULL address is defined behavior on almost all platforms and typically causes the OS to send SIGSEGV.