[pron]

I disagree with your analysis. Value types are being added (that's what the HotSpot team is busy working on) with relatively precise control over memory layout, and their negative impact only became clear when random memory access became more expensive (in relative terms). Still, Java performance isn't "killed" for the simple reason it handily beats Go, and often enough beats C++ in large, multithreaded programs. So if this is what Java performance looks like when it's "killed" by lack of value types, I'm very hopeful at the prospect of adding them, because Java will have no competition then, let alone Go, which lags behind even now. Large, big-data analytics software (like H2O) written in Java achieves 100% of maximum hardware performance ("Fortran speed"). The trend is that more and more performance-sensitive applications are transitioning from C++ to Java. Also, Quasar adds true fibers ("goroutines") to Java.

Now, I don't know exactly what you mean by memory consumption, but if you mean total memory consumption by the JVM, that's a feature of the GC chosen, which usually trades extra RAM for added performance -- it certainly does not negatively affects performance.

As to point 2, I think that was Java's greatest decision (which Go can't replicate), because the malleability of bytecode afforded by class loaders and agents have made the JVM extremely flexible while at the same time extremely performant. At the language level, annotation processors -- really, AST transformers -- are extremely powerful (see the new pluggable type systems for Java 8) and not easy enough to abuse by under-qualified developers. If you want a more powerful language, the JVM offers quite a wide selection, which is another thing Go cannot do.