4 ms·
> Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 9
by Measter 11mo ago
> Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.
One thing I've noticed when people make these arguments is that they tend to ignore the fact that most (all?) of these other safeties they're talking about depend on being able to reason about the behaviour of the program. But when you violate memory safety a common outcome is undefined behaviour, which has unpredictable effects on program behaviour.
These other safeties have a hard dependency on memory safety. If you don't have memory safety, you cannot guarantee these other safeties because you can no longer reason about the behaviour of the program.
- Animats 11mo agoHerb Sutter's article on this.[1] For C/C++, memory safety is a retrofit to a language never designed for it. Many people, including me, have tried to improve the safety of C/C++ without breaking existing code. It's a painful thing to attempt. It doesn't seem to be possible to do it perfectly. Sutter is taking yet another crack at that problem, hoping to save C/C++ from becoming obsolete, or at least disfavored. Read his own words to see where he's coming from and where he is trying to go. Any new language should be memory safe. Most of them since Java have been. The trouble with thinking about this in terms of "95% safe" is that attackers are not random. They can aim at the 5%. [1] https://herbsutter.com/2024/03/11/safety-in-context/ https://herbsutter.com/2024/03/11/safety-in-context/
- vlovich123 11mo ago> Most of them since Java have been The most popular ones have not been necessarily. Notably Go, Zig, and Swift are not fully memory safe (I’ve heard this may have changed recently for swift).
- testdelacc1 11mo agoCould you expand on how Go isn’t memory safe?
- tialaramex 11mo agoGo'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 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 11mo 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 11mo 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 11mo 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)
- winterlights 11mo agoSimilar to how Rust clearly is not memory safe, Go is also not memory safe.