3 ms·

Could you expand on how Go isn’t memory safe?

tialaramex 11mo ago
Go's memory safety blows up under concurrency. Non-trivial data races are Undefined Behaviour in Go, violating all safety considertions including memory safety.
- Animats 11mo ago
  Go maps don't have enough locking to be thread safe, as I understand it. That was true at one time. Was it fixed?
  - tialaramex 11mo ago
    I would not expect that it makes sense to provide this as the default for Go's hash table type, my understanding is that modern Go has at least a best effort "fail immediately" detector for this particular case, so when you've screwed this up your code will exit, reporting the bug, in production and I guess you can curse "stupid" Go for not allowing you to write nonsense if you like, or you could use the right tool for the job.
- pjmlp 11mo ago
  While that keeps being given as example, Go is not C, C++, Objective-C levels of memory corruption opportunities. Lets not let the perfect be the enemy from good. Even with all my criticism of many Go's design decisions, I rather have more infrastructure code being written in Go than C, and derived languages. Or any of the supposed better C alternatives, with manual memory management and use after free.
- frou_dh 11mo ago
  Isn't it strange that they created a new language where one of its main selling points is concurrency, and punted on that design issue. (Yes I'm aware that Go literature 'encourages' the use of Channels and certain patterns)
winterlights 11mo ago
Similar to how Rust clearly is not memory safe, Go is also not memory safe.
- vlovich123 11mo ago
  Not sure what this is saying but you can create a trivial concurrent program that violates the memory safety guarantees Go is supposed to provide [1]: https://biggo.com/news/202507251923_Go_Memory_Safety_Debate https://biggo.com/news/202507251923_Go_Memory_Safety_Debate That is not true of Rust.
  - quotemstr 11mo ago
    > [You can] create a trivial concurrent [Go] program that violates the memory safety guarantees ... > That is not true of Rust. It's not supposed to be, but Rust does have plenty of outstanding soundness bugs: https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22I-unsound%22 https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la... Rust as intended is safe and sound unless you write u-n-s-a-f-e, but as implemented has a ways to go.

Go's memory safety blows up under concurrency. Non-trivial data races are Undefined Behaviour in Go, violating all safety considertions including memory safety.

Animats 11mo ago
Go maps don't have enough locking to be thread safe, as I understand it. That was true at one time. Was it fixed?
- tialaramex 11mo ago
  I would not expect that it makes sense to provide this as the default for Go's hash table type, my understanding is that modern Go has at least a best effort "fail immediately" detector for this particular case, so when you've screwed this up your code will exit, reporting the bug, in production and I guess you can curse "stupid" Go for not allowing you to write nonsense if you like, or you could use the right tool for the job.
pjmlp 11mo ago
While that keeps being given as example, Go is not C, C++, Objective-C levels of memory corruption opportunities. Lets not let the perfect be the enemy from good. Even with all my criticism of many Go's design decisions, I rather have more infrastructure code being written in Go than C, and derived languages. Or any of the supposed better C alternatives, with manual memory management and use after free.
frou_dh 11mo ago
Isn't it strange that they created a new language where one of its main selling points is concurrency, and punted on that design issue. (Yes I'm aware that Go literature 'encourages' the use of Channels and certain patterns)

winterlights 11mo ago

Similar to how Rust clearly is not memory safe, Go is also not memory safe.

vlovich123 11mo ago
Not sure what this is saying but you can create a trivial concurrent program that violates the memory safety guarantees Go is supposed to provide [1]: https://biggo.com/news/202507251923_Go_Memory_Safety_Debate https://biggo.com/news/202507251923_Go_Memory_Safety_Debate That is not true of Rust.
- quotemstr 11mo ago
  > [You can] create a trivial concurrent [Go] program that violates the memory safety guarantees ... > That is not true of Rust. It's not supposed to be, but Rust does have plenty of outstanding soundness bugs: https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22I-unsound%22 https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la... Rust as intended is safe and sound unless you write u-n-s-a-f-e, but as implemented has a ways to go.