gVisor is a security product (
Container Runtime Sandbox ) made by Google in Go and runs in production so I'm not sure what you mean by "how vitally important security is in that domain".
a) In terms of memory safety, Go is not memory safe in the presence of data races, and Go does not prevent data races at compile time.
On top of this Go does not enable ASLR on most OS's. That means that when Go loads code from other languages, such as C/C++, memory safety issues in those languages are extremely easy to exploit relative to in a language like Rust, which enables tons of mitigation techniques by default.
b) More loosely, Rust has a more expressive type system. It is, in my experience, much simpler to enforce constraints in a 'type driven' way. In my opinion, this leads to safer software.
As an example of (b) I have written authentication code that encodes the authentication protocol's state machine into the Rust type system. What this means is that it is impossible to jump between two states in an undefined way. Beyond that, because of Rust's affine type system, it is impossible to reference invalidated states.
For authentication code, especially when you add complex stateful transitions such as rate limiting, whitelisting, etc, this is an extremely effective way to reason about your security critical code.
I think there is a case to be made that there is a real, significant difference between the languages regarding security.
One could make an argument about data races, for example. Rust prevents them at compile time, Go does not.
You could also make an argument about compile-time guarantees more generally.
I'm not sure it's really a great argument, but you could make it. I think the parent's statement that it's only Go because it's made by Google is demonstrably false.
One could make the same kind of argument with GC lang vs none GC ( RAII doesn't protect from everything ). OP said "much safer" Rust is not much safer than Go, maybe it is safer but definitely not "much safer"
You're the one that said "Google is emotionally attached to Golang, which was born at Google." which is really stupid tbh you think engineers at Google pick up tech because they're "emotionally attached"? Those smart people took the tool that fits their needs.
I'm sorry, but Google isn't some role model with high values. On the contrary, it makes most of its money from selling our dirty underwear to merchants.
I'd say on the contrary. They chose it even while knowing they'll gonna need to hack generics. (Same in k8s, generics hacked together in a few different ways)
It's quite likely that, being at Google, they were already familiar with Go, people around them were using it, and there was a comfort factor with it being a Google project.
It's rational to take these factors into account, but they don't reflect on the merits of the language itself, and aren't necessarily transferable to other people choosing programming languages.