No one's mentioned the revolutionary perspective of this story: learning a JVM language in its own right, without regard to the JVM, nor Java, its libraries nor

No one's mentioned the revolutionary perspective of this story: learning a JVM language in its own right, without regard to the JVM, nor Java, its libraries nor infrastructure. Most JVM projects do have regard to Java, because: the developers know Java and indeed are using it; and access to Java libraries and infrastructure is a key selling point. But it doesn't need to be that way. You can treat the language like a clean abstraction: most python programmers don't worry about the C underneath; most C programmers don't worry about the assembly underneath; most assembly programmers don't worry about the hex underneath. This a different way of seeing a JVM language. It seems that the problems mentioned are common to all JVM languages (I was especially struck by similarities with JRuby, recently on HN). Ideas: (1) look at other JVM languages. Copy their solutions. (2) someone develop a "JVM language support environment". It might include eg. a java server, so startup times disappear. (the JVM is damn fast, once it's going. And, kinda freaky to witness, it gets perceptibly faster, through JIT). Oracle might even include subsume it into Java, should it serve their business interest.