[Animats]

Herb 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/

[vlovich123]

> 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]

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

[tialaramex]

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

[pjmlp]

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.

[Animats]

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]

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.

[frou_dh]

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]

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

[vlovich123]

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

That is not true of Rust.

[quotemstr]

> [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%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.