Same can be said for the JVM vs CLR, only in reverse.

JVM doesn't even have value types or generics making it practically unusable in some scenarios. While JVM implementations might be better quality for specific problem domains I'd say CIL is probably better than JVM.

Not to mention CIL was designed to be a Common Intermediate Language from start so language interop is nicer (generics are a nice example)

> 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.

here's a quick gif demo: http://bit.ly/1k7nG2n

Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)

It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages.

Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.

> It's not like Scala has generics interop with Java

Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode.

> you can't use advanced Scala generics from Java

I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it?

> I'm sure they could have erased the extra stuff on CIL

Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics.

As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all).

> Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.

That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...

Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-stud...

Apparently baking the generics into the generated bytecode has downsides in flexibility.

Do you have any links on this? I had a quick duckduck but sadly nothing much came up.

My understanding of 'type erasure' is that it is a compiler step, that un-does all the generic information.

This means that you could just ignore CLR generics, interop not withstanding, to get it to run.

Why would this prevent anything been ported?

I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.

Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.

Technical aspects are almost irrelevant.

For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM.

The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box.

A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects.

[1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.

Well, as it turns out, that was just Microsoft's marketing. They did have a head start, but they dropped the ball on that one ever since .NET 2.0.

Would you mind expanding on what you think is modern about C#?

Async, lambdas, extension methods, linq and "the dynamic type" (late binding). Yes, many similar but older implementations for these exist, I know, but in C# they work in harmony - and that's a bit hard to explain for me =)

And more syntactic sugar than is good for your teeth :) (I'd also want to add generics to the list, but it's over 10 years old, still not many languages that implement it so well)

Type inference.

Properties, lambdas (thought they have it in Java 8, but it is still too late) to start with.