> JVM doesn't even have value types or generics making it practically unusable in some scenarios
Like what?
The CLR is unusable for dynamic languages for example. I was using Ruby back in the day, when both IronRuby and JRuby were active at the same time, with IronRuby/IronPython being developed by Microsoft ... there was no comparison to speak of, JRuby was beating the pants out of IronRuby in terms of everything.
The JVM can inline virtual method calls, the JVM can do escape analysis for getting rid of unneeded locks or to allocate short-term objects on the stack, the JVM can de-optimize previous optimizations in case assumptions have changed or in case it doesn't see a performance improvement, the JVM has a GC that can cope with the garbage produced by dynamic or FP languages. The JVM has invokeDynamic.
As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing) and many others, including a Haskell port. All of them with thriving communities.
> Not to mention CIL was designed to be a Common Intermediate Language from start
That was just marketing. The JVM's bytecode is actually better for other languages. At the very least, the debugging symbols are part of that bytecode and the format is documented.
>As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing).
Speaking of those, if anyone wants to try those languages on the jvm for web app development check out HiveMind (crudzilla.com)...I am the developer, it is the easiest platform so far for using JSR-223 to build web apps.
Like what?
The CLR is unusable for dynamic languages for example. I was using Ruby back in the day, when both IronRuby and JRuby were active at the same time, with IronRuby/IronPython being developed by Microsoft ... there was no comparison to speak of, JRuby was beating the pants out of IronRuby in terms of everything.
The JVM can inline virtual method calls, the JVM can do escape analysis for getting rid of unneeded locks or to allocate short-term objects on the stack, the JVM can de-optimize previous optimizations in case assumptions have changed or in case it doesn't see a performance improvement, the JVM has a GC that can cope with the garbage produced by dynamic or FP languages. The JVM has invokeDynamic.
As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing) and many others, including a Haskell port. All of them with thriving communities.
> Not to mention CIL was designed to be a Common Intermediate Language from start
That was just marketing. The JVM's bytecode is actually better for other languages. At the very least, the debugging symbols are part of that bytecode and the format is documented.