4 ms·
Rust is not safer than Go, people thinking otherwise misunderstand borrow checker vs GC. Furthermore you're talking about memory safety vs business logic bugs,
by Thaxll 7y ago
Rust is not safer than Go, people thinking otherwise misunderstand borrow checker vs GC.
Furthermore you're talking about memory safety vs business logic bugs, two different things.
- pcwalton 7y agoGo is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior. I haven't heard of this causing a problem in practice, though.
- Thaxll 7y agoI never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption. Please give us a code example.
- skybrian 7y agoSlice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it. (I haven't seen this happen, though.)
- pcwalton 7y agoYes, not synchronizing a slice can lead to memory corruption in Go.
- staticassertion 7y agoHere you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.
- psanford 7y agoHere's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace https://research.swtch.com/gorace
- deleted 7y ago[deleted]
- cwzwarich 7y agoAre all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.
- pcwalton 7y agoUnfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)