Go is not going to replace Java in the future. For a language which cannot even lock dependencies to a version, people sure like to pretend it is the holy grail because Google made it.
So what happened was that many of these packages existed pre-1.0 when there was no stability system. Nobody knew which features would be stabilized (if you go further back, the fact that things would be stabilized in such a way wasn't clear either).
So we all just used whatever feature we liked. Many of these unstable APIs or features had stable counterparts, but the choice to use an API/feature was made pre-stability, so nobody had any way of knowing. Which meant that a lot of unnecessary unstable API usage persisted after 1.0. Some crates made a transition. some were slower (I think hyper was pretty quick to stabilize). Servo, for example, didn't have any issue with using nightlies for various reasons so we kept using unstable APIs (I later audited and removed low-hanging extraneous unstable API usage. Most of our out-of-tree crates are stable too).
There have been efforts both by maintainers and by individual community members to bring crates to stable, and I think at the moment most useful non-plugin crates work fine on stable. Let me know (@Manishearth on twitter) if you find a crate that you need that doesn't work on stable!
I can read Go easily enough, I haven't done any major writing in it (yet), other than some minor work on Hugo trying to help to nail down/replicate a bug. It was easy enough that I think I'd pick it up quite fast, the syntax feels 'weird' to me but that's most likely just unfamiliarity.
- Nobody in their right mind would choose Rust or Javascript for a project where the other is more appropriate.
Though (AFAIK) Scala and Clojure both interop quite well with Java, and Scala/Clojure interop isn't terrible either, plus there's definitely a culture of reusing in Clojure/Scala all the stuff that the Java ecosystem already had. So this cluster isn't causing much fragmentation at all.
You have something of an argument that Go and the JVM languages clash for mindshare, but at that point the argument around really annoying fragmentation has kind of lost steam.