Kind of like Java in general, the JVM sits in the middle ground. LLVM is a good starting point for building low level languages (although nothing prevents you from writing high level languages in it, you just have write more). The HLVM is supposed to be a good starting point for building high level languages with things like garbage collection, closures, tail call elimination, etc. The JVM isn't the fastest for low level applications and isn't the easiest for high level functional languages.

The JVM is a great platform if the language in question is relatively close to Java, and you're just layering on higher-level syntax like closures. (Sure, it would be nice if Java supported them, but they're not hard to implement as anonymous inner classes, and to simulate real closing over variables you just need to wrap all captured variables in one-element arrays or other wrapper objects at the declaration side. It's annoying, but it's livable).

The further you move away from the Java typesystem or execution model, the less fun your life will be and the fewer benefits you'll get from the JVM: moving to dynamic typing will cost you a large amount of performance, for example, and you'll have to fight the Java type system a fair amount. I can only imagine what it would mean to do lazy-evaluation in a JVM language.

If it matches what you're trying to do, though, it's really a great platform: the bytecode format is pretty simple and easy to learn, the JVM runs of pretty much any platform you need, and it does a huge amount of optimization for you. If you're doing a statically-typed language and compiling down to Java-like bytecode (as opposed to handling dispatch yourself, as you have to do in a dynamically-typed language), you also basically get debuggers and profilers for free.

It's definitely a little weird, though, that they'd set up the motivation for HLVM as due to the weaknesses of the CLR's cross-platform capabilities, without mentioning the JVM at all, given that the JVM was, in spirit at least, the precursor to the CLR and still the most widely-used higher-level VM and one that works basically everywhere.

Maybe it is because the strategy more closely resembles the relationship between the CLR and DLR than the JVM and nothing. Like you said the JVM is not dynamic language friendly, and Sun/Oracle has really shown much interest in making it so.

(I am having a bit of an issue parsing the last sentence but I guess it was "hasn't")

Isn't the DaVinci/MLVM project an example of how Sun actually tried to move towards dynamic and non-java languages in the JVM? invokedynamic & method handles are already in the upcoming java 7, and that goes a long way towards supporting dynamic languages on the JVM.

Yes, I meant hasn't. Sorry for not proof reading.

The great advantage of the JVM is it has tons of libraries. This means that any competitor such as HLVM will have to fight very hard to gain traction.

That is part of the allure of being built based on LLVM. Recompile some C and C++ libraries using the gcc or clang front-end to LLVM and now HLVM has ton of libraries it can access.

I've always felt that the JVM seems to be a bit of an outsider - where the CLR seems tightly integrated. Whether this is due to the startup time, the need to start apps by invoking "java ..." rather than directly, or some other factor, I'm not too sure.

I know that I could add options for .jar files to automatically invoke the JVM, but then not all use a Main class, so that's not a guaranteed fix.

Maybe with the new generation of "cool" languages for the JVM we may start to see some change on this front. Oracle may have some interesting ideas as well, as new "owners" of the Java platform...