Edit: To clarify I mean if you had a Java X app deployed how hard is it to upgrade to Java 8? One thing I like, maybe naively, about Go is static binaries.
It's pretty trivial. 1. Upgrade JVM on server (i.e. change 1 line of puppet config) 2. Build with Java 8 (i.e. change target option in your build file) 3. Deploy.
I mean sure, you have to install the new JVM, but if you don't have a system in place for making changes to your servers then you've got bigger problems than which language you're using. And honestly I think the JVM with its classpath approach solves the library problem better than most platforms; upgrading the JVM binary occasionally is no great hardship, and aside from that everything is just jars, dynamic but not getting in the way of each other unless you want them to. What happens when security holes are found in Go libraries, do you have to recompile anything that depends on them?
Personally, no, not yet. My current employer has been dragging its feet over Java upgrades, so we're only just transitioning onto Java 7.
However, most of the work involved in doing that is paving the road so that version upgrades are faster. I would anticipate that moving from 7 to 8 will be much faster than moving from 6 to 7.
Edit: To clarify I mean if you had a Java X app deployed how hard is it to upgrade to Java 8? One thing I like, maybe naively, about Go is static binaries.