3 ms·
Confused, aren't they losing memory safety? I get for certain core code situations, you want to manage all memory safety yourself (or use built in static GC),
by blazespin 7y ago
Confused, aren't they losing memory safety?
I get for certain core code situations, you want to manage all memory safety yourself (or use built in static GC), but beyond that it seems to me at a higher level you'd rather have the automatic GC. Why burden all of your developers rather than just a core few?
I don't think GC issues is a compelling argument to move everything to Rust. I'm not saying there aren't compelling arguments, but that just seems a bit odd that that's their main argument.
- echeese 7y agoNah, guaranteed memory safety is actually one of Rust's main selling points
- buzzerbetrayed 7y agoI’ve never heard the argument that moving to rust reduces memory safety. Isn’t memory safety what rust is known for?
- Matthias247 7y agoIt is! But in Rust you still have an escape hatch in the form of the `unsafe` annotation which allows for mistakes which break memory safety. I don't think Go has something like that, unless you use the FFI. So saying that Go is at least as memory safe as Rust might not be too wrong of a statement. However I think in total Rust is safer. E.g. Rust prevents a ton of race conditions in multithreaded code, which Go can not do.
- Jweb_Guru 7y agoGo has data races on multiple cores in safe code, without using any unsafe intrinsics or C FFI.