I was unclear: the key bit from that first sentence is "any failures are flagged". Go does give more static control over stack vs. heap than Java, but it's stil

I was unclear: the key bit from that first sentence is "any failures are flagged". Go does give more static control over stack vs. heap than Java, but it's still perfectly happy to implicitly promote things to the heap to make code work. This means that Go offers less control over memory (one of the things needed in a low-level language) than Rust. When, for instance, variables are being passed between threads/goroutine-equivalents, Rust will notice that things are trying to escape and tell the programmer that they need to decide how they want to handle it, rather than make the decision implicitly. (The Go approach isn't like C++ either, which also doesn't implicitly allocate, like Rust.) There are many other aspects in which Go does not offer as much control as Rust, e.g. the former incorporates a runtime and garbage collector. This isn't disagreeing that Go offers more control than Java, but Rust (and C++) offers even more than Go.