4 ms·
Go's memory safety blows up under concurrency. Non-trivial data races are Undefined Behaviour in Go, violating all safety considertions including memory safety.
by tialaramex 1y 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 1y agoGo maps don't have enough locking to be thread safe, as I understand it. That was true at one time. Was it fixed?
- tialaramex 1y agoI 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 1y agoWhile 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 1y agoIsn'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)