Hacker News Reader

Comment by neel_k | Hacker News Reader

It's taking on a fair amount of risk to use a language that (a) encourages the use of concurrency but (b) is not memory-safe when you do so, especially when writing network-facing code.

Go uses multi-word primitive values, which means assignments are not atomic. Consequently, racing assignment statements can leave objects in weird states that violate type and gc invariants. For example, racing assignments to a value of interface type can give you an object with the wrong dictionary for its data.

The argument for not worrying about this is that this is an unlikely scenario. It's reasonable to think in probabilistic terms when clients are not trying to break the software (eg, in games or office software). However, attackers are not probabilistic: they actively search out vulnerabilities and push on them, so potential vulnerabilities turn into actual vulnerabilities in predictable fashion.

View on HN

Go definitely doesn't encourage code where multiple goroutines directly modify the same values. You're supposed to use channels for communication between goroutines by default.

Rust also lets you write memory unsafe multithreaded code, if you want to.

> Rust also lets you write memory unsafe multithreaded code, if you want to.

That's a false equivalence. Nobody is criticizing Go for having an `unsafe` package. The criticism is that your Go code can be undefined without using the `unsafe` package. In Rust, you need to use `unsafe` in order to write code that has data races. Otherwise, data races are statically prevented in safe code, unlike in Go.

You don’t need to use 'unsafe' yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe.

The situation with Go is pretty clear. Channels are safe. If you start mutating shared state across different goroutines, then you’re in the same situation you’d be in if you were doing the same thing in C++. Anyone who doesn't understand why that's potentially unsafe wouldn't be ready for Rust in any case.

> You don’t need to use ‘unsafe’ yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe.

Sigh. That's true of Go too. Both Rust and Go have `unsafe` labels that give access to dangerous things that can cause UB. Both Rust and Go are susceptible to UB-at-a-distance if library code internally uses `unsafe` incorrectly. The difference is that, in Go, you can write code with data races without using any `unsafe` at all. Nothing will yell at you (unless you exercise the race in a test and run the race detector). Rust does not suffer from this flaw.

I've been writing both Rust and Go since before each had their 1.0 release, and I like both languages. This isn't some back-handed comment about how I think Go is bad because of this. I rarely trip over data race related bugs in Go, but they do happen, so they aren't a huge issue in practice. (And your continued mention of channels is a red herring. Go has mutexes and idiomatic code uses mutexes quite frequently. Channels are not always the right thing to use.) Nevertheless, the comments here comparing Rust and Go are a fairly important mischaracterization of how each language treats memory safety, and it's important therefore to correct that.

>Sigh. That's true of Go too.

Yes I know. I'm not sure why you think I'm saying that this is not true of Go.

>The difference is that, in Go, you can write code with data races without using any `unsafe` at all

Again, I know. I addressed this in my previous comment.

Less sighing, more reading!

Yes, I'm sure you're aware. But the way your comments are written are pretty misleading, so I'm trying to clarify them. If you don't think the clarifications are beneficial to you, then treat them as clarifications for anyone else who is reading.

> Anyone who doesn't understand why that's potentially unsafe wouldn't be ready for Rust in any case.

That's most certainly not true. They might not be ready to write high performance generic data structures from scratch, but application level code in Rust generally has about as much explicit `unsafe` as application level Go code, in my experience. (And writing high performance generic data structures isn't really a thing in Go. Not nearly as much as in Rust anyway.)

I don’t think you are clarifying them so much as misreading them.

I'm confused by the second paragraph of your response. My point was that the lack of an explicit 'unsafe' block in Go isn’t that much of an issue, as pretty much everyone knows that Go does not make any memory safety guarantee when accessing shared state from different Goroutines. Anyone who doesn’t know this isn’t ready to get their head around writing multithreaded code in Rust. Rust’s features for doing this are cool, but they require a pretty good understanding of Rust’s complex type and lifetime system.

What a strange argument. "Pretty much everyone knows" that C/C++ aren't memory safe even for sequential code, and that it's incredibly easy to trigger thread-safety bugs in C/C++. But since "pretty much everyone knows", I suppose that makes it OK?

> Anyone who doesn’t know this isn’t ready to get their head around writing multithreaded code in Rust.

Well, if they aren't using `unsafe` in the process (or, to be fair, relying on buggy library code that uses `unsafe` inappropriately), they're not going to introduce memory unsafety via data races - no matter how "ready" they are. You just can't say the same about C/C++. Or even Go.

I don’t recommend that people use Go to write complex multithreaded code that accesses shared state. My point is that I doubt many people are doing this while erroneously thinking that their code is guaranteed to be memory safe. In other words, whatever the problems with Go may be in this regard, it’s not primarily the absence of an ‘unsafe’ keyword that’s the issue.

> I don’t recommend that people use Go to write complex multithreaded code that accesses shared state. My point is that I doubt many people are doing this while erroneously thinking that their code is guaranteed to be memory safe. In other words, whatever the problems with Go may be in this regard, it’s not primarily the absence of an ‘unsafe’ keyword that’s the issue.

I think the point here is that if the word "unsafe" exists as a language construct, someone is not wrong in assuming anything without that mark is safe. Otherwise, why isn't there a "safe" language construct?

That’s true to an extent, but it’s important to bear in mind that you can’t lexically scope memory unsafety. Rust code that doesn’t contain an 'unsafe' block should be safe assuming that all of the libraries it’s built on are safe. But those libraries may well contain 'unsafe' blocks that are (one hopes) carefully written to be memory safe.

Admittedly, my understanding of the problems you describe is superficial at best. But it sounds like you are citing a rather narrow set of requirements (memory safety in network code where protection against exploitation is paramount) as a means to generalize that Go is overall not a good language and should be avoided in new code. I don't think that's fair. As with everything, it may be not suitable for the scope you outlined, but it evidently has its place in a multitude of other uses.

“Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.

No, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace

Is there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.

Presumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.

Go is indeed memory-safe for sequential code, but non-atomic assignment can definitely break memory safety in multi-threaded settings - it's effectively a data race.

Reply on news.ycombinator.com