I think all those points are covered by Go. And Go is more succinct. It was trivial to cross-compile Go executables on my Mac for Windows and Linux.
Haskell and Rust cover the same space as well. HN seems to have some weird obsession with Go at the moment, but the reality is that outside of this little bubble no-one knows or cares about Go. I use "no-one" in the to-within-rounding-error sense, not the literal sense. Go may gain sufficient mindshare in the future that it gains a space in the average developer's head as their goto tool for a certain job but it isn't there yet.
While we're at it, Java is not the only language on the JVM. For example, Scala is growing fast and it has polymorphism AND sane error handling (http://www.scala-lang.org/archives/downloads/distrib/files/n...), features which AFAIK elude Go.
I would think HN has a very broad readership across many occupations. Dismissing Go as an HN bauble seems very odd. The point is that I enjoy Go, and it handles all the things you mention and a few more within its sweet spot. And it works well even now, immature that it is. It's a reasonable alternative to the JVM for lots of problems.
Go is also most pertinent from the Python perspective because it's probably gaining recruits from that community instead of the C/C++ community.
Go certainly has polymorphism. Also, I've written about ~30,000 lines of Go thus far, and the programs I've produced have by far the best error checking than any other program I've produced with another language. I think that at least qualifies as "sane." (Particularly since I find my error checking to be easy to write and easy to read.)
* Go makes it a lot easier to interface with native libraries than Java ever will. I think anyone who has ever written JNI can confirm that it is a nightmarish interface. JNI also has performance problems, to the point where using an optimized C implementation through JNI is often slower than writing the same thing in Java.
* Java definitely has more libraries available. However, partly because of point #1, Go is catching up quickly. It's very easy to wrap C libraries in a Go interface with cgo.
Also, a lot of the old Java code and frameworks smell kind of funny. Do you want to write a new AWT application in 2012? Really? Yeah, Java has more stuff, but... is it kind of stuff you actually want to use, or the kind of stuff you find at the thrift store?
* Go exposes more OS-level features than Java. For example, Java didn't get a way to create softlinks until JDK7.
* Java does not provide a built-in solution to dependency management. The CLASSPATH mechanism essentially punts the problem to the individual developer. It seems easy enough to dump all your jars in a folder and call it a day, but eventually you end up in a situation where library X depends on library Y, which depends on library Z, which depends on a different version of library X. Hmm. Guess you are in trouble! With Go, this problem does not exist because things are compiled statically, and Go has standardized library paths.
Maven and OSGi were both attempts to solve the dependency problem in Java-land. However, since they weren't standard parts of the language, they felt clunky and bolted-on. Maven also combines the functionality of apt-get, Makefiles, and distcc in one giant monolith, which can make debugging... interesting.
* Partly because of the complexity of Java classloaders, a number of security vulnerabilities have been discovered recently.
* Go programs have a miniscule startup time, whereas the JVM takes a lot of time to start. This seems like a very minor point, until you realize that for things like command-line utilities, it makes Java a real performance-killer. This is one often-overlooked reason why Java fizzled in the browser but succeeded on the server.
polymorphism AND sane error handling [elude Go]
Go has polymorphism. I like Go's error handling a lot-- but this topic has been discussed elsewhere.
Other technologies will have their own ecosystem. Which will grow at their own pace as demand for that grows.
Is there anything in particular that's available in Java that you couldn't get in Go or Python?
A cross-platform UI toolkit that's pretty good all things considered? A reporting toolkit that produces PDFs according to custom templates?
(Swing and JasperReports, respectively)
Next step on the ladder is languages. You can mix any combination of Java, Scala, Groovy, Clojure, JRuby, Jython and others with little or no friction.
Then there's infrastructure. There's a good selection of rock solid application servers - Tomcat, Jetty and Glassfish comes to mind. The entire JDK toolchain, especially VisualVM, JConsole and JMX. Get a stacktrace or a heap dump from a running java process? Trivial and built in.
Finally, the libraries: JDBC is pretty neat: Every database under the sun plugs into the same interface. Terracotta has a pretty interesting line up (http://terracotta.org/products). Hadoop - it's a full ecosystem of it's own. Eclipse and IntelliJ IDEA. Apache POI for MS Office doc manipulation. Apache FOP is supposed to be pretty powerful. Lucene. Apache Commons.
Recruiting for Go is not nearly as easy as for Java.