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.