5 ms·
> BTW, Rust has this problem more than other memory-safe languages Do you have a citation there? I've run into a ton of memory safety issues in Go because two
by TheDong 2y ago
> BTW, Rust has this problem more than other memory-safe languages
Do you have a citation there?
I've run into a ton of memory safety issues in Go because two goroutines concurrently modifying a map or pointer is a data-race, which leads to memory unsafety... and go makes it wildly easy to write such data-races. You need to manually add mutexes everywhere for go to be memory safe.
Rust, on the other hand, I've yet to run into an actual memory safety issue. Like, I'm at several hundred in Go, and 0 in rust.
I'm curious why my experience is so different.
- commandersaki 2y agoI think the key is "as they depend on operations or components that may not themselves be fully memory-safe" indicating Rust is used a far bit more to do interop with memory unsafe languages unlike Go or Java.
- meltyness 2y agoI sense OP's referring to raw pointer operations permitted by the unsafe dialect of the language.
- pron 2y agoIt is more common (and/or more necessary) to either write unsafe code or call out to unsafe code written in some other language in Rust than in Java. BTW, I wouldn't call a language that violates memory safety without an explicit unsafe operation a memory-safe language.
- fpoling 2y agoRust compiler assumes that unsafe code still follows the borrow rules and optimizes code based on that. So if that is not the case, the consequences can be bad. For example, there was a bug in Rust OpenSSL bindings where OpenSSL had not documented the proper life time of some of the function arguments/return types. As the result unsafe code containing the call to OpenSSL C implementation violated Rust memory model leading to crashes. But I agree that such problems are rare in Rust and Go races are much more problematic.