Go has a much different set of design goals than Zig, Nim, or especially Rust. Go is really for people who want a few major improvements on C like easier builds, faster builds, higher-level standard string handling, direct support for some form of concurrency, an optional GC which defaults to on, and a few syntax tweaks - things that a modern C might have that were not going to make it into a standards revision. Rust, to support ownership and the borrow checker at compile time, had to build a useful language around that hugely helpful but quite restrictive requirement. They subsequently went different directions than the Go team on a lot of the other language features. Zig, Nim, and D are something in between those extremes in their own ways.

As someone with a background of a lot of time with Perl and the Pascal/Ada family who was rooting for Julia, Go strikes a good balance for me where I would have used Perl, Python, Julia, Ruby, or shell for system tasks. I haven’t done a lot of work in Rust yet, because in the infrastructure space speed to implement is usually more important than performance and Go is a lot faster already than Python or Ruby and because my team as a whole has much more experience with it. I certainly appreciate why the folks at work who do the performance-critical network and video software use mostly Rust to do what they used to do in C, Java, or C++.