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 w

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.