Hacker News Reader

Comment by saghm | Hacker News Reader

Memory safety as long as you don't violate certain rules is what C and C++ also have. The problem is that programmers make mistakes because we're all human.

View on HN

No, the "mistakes" we talk about with C/C++ are so common that it's hard to think of a major C/C++ project not to have them, and the "mistakes" we're talking about with Go or "unsafe" Rust are contrivances built to demonstrate things an actively malicious programmer could do. Equating the two is, obviously, a sleight of hand.

To add to this: the built in go race detector is very good at catching data races. It’s a runtime, but I’ve never had a race that couldn’t be reproduced in the race detector trivially.

But yes, in theory Go has a memory safety problem because of it. In practice though, it’s that people don’t use the race detector, which is ridiculously easy to do.

Ordinary non-race-checked Go code is memory-safe in the sense that we mean it in the field of software security.

"We"? Do you have a mouse in your pocket?

It's only on Go, leave Rust out of it. Rust's safe part is entirely memory safe. Unsafe is the escape hatch, which pretty much every language has in the form of FFI.

That's not true: idiomatic Rust projects use `unsafe` much more liberally than other languages use FFI, because of shared xor mutable. That's not a knock on Rust. I couldn't be less interested in Rust vs. Go; I use both and would use them both in different situations.

I doubt that "idiomatic Rust projects use unsafe liberally". It is a more liberal construct, perhaps, but IMO actual usage is usually reasonable. Unless you mean the standard libary's use of unsafe?

I'm not saying it isn't reasonable, just that it serves a different role in Rust than unsafe/JNI would in Java: there are things you naturally want to express in Rust, not having anything directly to do with interfacing with external code, that want `unsafe` in order to (carefully) bypass shared xor mutable.

> Memory safety as long as you don't violate certain rules is what C and C++ also have

There are numbers between 0% and 100%, thus it's possible that Go can be less than 100% memory safe and still far safer than C or C++.

"100% memory safe" is mostly not a thing; it's not a concept that gets quantified this way. The closest thing I think you get to a compromised notion of safety that's actually noteworthy is Zig's allocator behavior (which can in ordinary code theoretically still produce UAF bugs, and UAF bugs --- lifecycle bugs more generally --- are the most pernicious kind of memory safety vulnerability). Most practitioners would still call Zig "memory safe". You can see how much bigger a deal that behavior is than the one we're talking about.

I think the basic takeaway here is not to tie yourself up in nots trying to quantify memory safety. There's a reason Prossimo calls Go memory safe (not "mostly memory safe"), along with Rust, C#, Java, Swift, Python, and JavaScript. Ordinary code written in any of these languages is just not going to have exploitable memory corruption vulnerabilities. Other vulnerabilities, yes!

I'm curious to hear why most practitioners would call Zig's allocators memory safe? Do you mean the std.heap.GeneralPurposeAllocator which protects against use-after-free when building in debug and release_safe mode (not release_fast)?

Reply on news.ycombinator.com