There's a larger variety of JVMs designed for a broader range of hardware, the most interesting to me being Azul and their GC tech.
But the CLR gives you some different tactical options. Value types and unsafe code let you do things that are far more expensive or awkward on the JVM. Writing a significant amount of functionality that does no heap allocation is more feasible on the CLR than JVM. Native interop is an order of magnitude easier. The CLR is generally much faster to start up; Java terminal apps don't suit interactive use. The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
True, although the most relevant difference is value types, which Java is getting, too. As to the rest, it's not about the number of features, but the quality of implementation. HotSpot's JIT and GCs are simply years ahead of the CLR, and HotSpot's next-gen JIT, Graal, is another tremendous leap forward.
> The CLR is generally much faster to start up
Compared to HotSpot, yes (but, like you said, there are many JVMs out there), although Java 9's JIT caching will change that.
> The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
This, too, is no longer the case in Java 9, but the difference in the other direction is much more relevant: the JVM's agent capabilities (both Java and native agents) are one of the things that give the JVM its power. The ability to easily transform code as it's loaded (or after its loaded) packs a lot of oomph.
In general I'd say that the JVM offers fewer abstractions, but more powerful ones and it offers less opportunities for hand-tuned optimizations and more for automatic optimizations. In the end, HotSpot is simply much more advanced internally. The CLR is like a car with more buttons, but HotSpot is the car with the better engine. HotSpot has always opted for constant change that's hidden from the user, while the CLR has been adding more and more user-accessible features.
The work being done on Graal/Truffle is so far ahead of anything anyone else is doing, that it will put HotSpot's JIT beyond the reach of any other technology for years to come. It seems to me that the CLR might even stop competing and C# might switch to AOT compilation, with VB possibly being abandoned. Some of the latest moves by MS seem to hint in that direction (RyuJIT was already done or nearly so).
- The biggest relevant difference -- which he mentions -- is indeed value types, which are coming to Java,
- The CLR doesn't have coroutines. Yield/await are what's known as "stackless coroutines" and are, AFAIK, implemented at the language level (and besides, stackless coroutines are a far cry from coroutines, as the most powerful concept of coroutines is the stack). The JVM, OTOH, offers such sophisticated bytecode manipulation capabilities that full coroutines can be implemented as a library (e.g. Quasar).
- What he says of bytecode/package design bears absolutely no relevance to the quality -- or power -- of the VM. Those are just simple design tradeoffs with little effect on results.
Also, see my reply to math.
A reference to back your statement up would be great... (i couldn't find a good one quickly). Are you aware of the capabilities of the CLR's next generation RyuJIT? What you say is at odds with what I thought, but I'd love my perceptions to be corrected if they are indeed incorrect.
Yes, some, but those differences are being quickly erased. The most important one is value types, which are being added to Java. See my reply to someone123.
RyuJIT's capabilities are nowhere near HotSpot's (I'd say they're about 7 years behind), and HotSpot's next-gen JIT (Graal) is another huge leap forward. The CLR's GC is also far behind HotSpot's selection, let alone offerings by other JVMs (there are many JVMs to choose from).