Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com