Yeah, Go being stable earlier, plus being so simple is great for its adoption. That said, Rust and Go have some overlap, but also areas where each is clearly the better choice. There's no reason this needs to be a zero-sum thing!
Yeah, they both have their use cases and they can both be popular equally. It's all about looking at the problem in hand and deciding what do you need to solve that problem.
Go is becoming the new Java from what I can tell so it's good to know enough to find your way around and patch a Go project if needed. Being the new Java, despite being less expressive, explains the uptake in the enterprise and startups.
If Java had good AOT and fast startup coupled with comparable initial GC heap sizes, it could have had a better chance at fighting off Go. Java will not go away and many teams that adopt Go also migrate to other languages at some point if their projects outgrow the capabilities of Go and the pain gets too strong.
I'm partial to GHC's language extension model over a cornucopia of Go pre- and post-processing tools like Java had (e.g. AspectJ and all the tools making use of annotations? or Go processors using comments). It will be easier to improve GHC's GC or complete OCaml's multicore branch than bring Go to the current century of proven programming language features. Go has found a niche as a replacement for C and Python in network programming, which is great. It just doesn't scale as well with project and team size. OCaml's multicore project also introduces algebraic effects (comprehensive alternative to monadic programming) to the mainstream, so I can't wait for OCaml multicore to land in mainline.
Java has had AOT support since version 1.0, available to anyone that understands the value of paying for our tools, just like in any other profession.
For those that rather get everything for free, OpenJDK has initial support of Linux x64, with other platforms being already available on OpenJDK 10 master.