Some Java folks are looking down on C#? I don't believe it :))
In my experience it's always been the opposite: C# guys have always looked down on Java folks. And rightfully so: the language itself is nicer, the standard library is much nicer, and the CLR+CIL are vastly superior to JVM, especially in memory management department.
>CLR+CIL are vastly superior to JVM, especially in memory management department.
This is an extremely disingenuous statement. You may be referring to the fact that the CLR/C# supports the notion of structs, and allows native memory management. However, as someone who has experience working on both the JVM and the CLR, I can say that the CLR's GC is primitive compared to the JVMs.
Biggest advantage off the top of my head is the JVM's garbage collector has a lot more tunable options. Different application's various heap profiles necessitate using them in high performance applications. I don't believe the CLR allows you to specify the size or number of various generations, or the number of collecting threads, all possible with the JVM collector(s).
Either way, the G1 trounces both the CLR and JVM's current collectors, so the JVM for java 7 will make the advantage even more apparent.
I'm less familiar with the internal workings of JIT compilers. I don't believe the CLR supports static analysis type optimizations, but perhaps the CLR team focused their research in other areas. If anyone knows more details on the differences in their JIT strategies I'd love to hear more.
Meh. GC isn't terribly interesting. It's just a tool to manage internal heap for a process. The issue with JVM is simple: it's a memory hog and it hates to reboot because JVM thinks of itself (and behaves) as a "computer" instead of a "process": it slowly boots instead of starting, it doesn't fork nicely, it doesn't share any code with its own clone running side-by-side, it allocates more RAM that it needs on startup, basically behaves like a drunk asshole in a bar, hence no Java on the desktop. Dalvik, on the other hand, is "JVM done right".
CLR processes are just processes. They're integrated into a native VM, they are capable of code sharing and they use more compact in-memory representations of built-in types. CLR was designed to run on machines we're running it on, not with a goal of selling more of "big iron". CRL is great for general purpose software development, without cowardly "long-running" or "on dedicated box" prefixes attached.
I agree that the JVM is a bigger memory douche than a vodka-and-Red Bull addict with a new haircut, but I disagree that GC is a "meh" problem. In fact it seems that the CLR is still evolving in this area and can have serious issues with multi-GB heaps -- as does Java unless you incant the right incantations:
Of course, one might say "don't use such big heaps dummy!" But that's a workaround. Due to fragmentation, sub-second GC latency is still a tough problem even for 1-2 GB heaps.
If C# would lead the way in a GC-friendly memory management scheme (maybe regions or something similar) they might win a lot of Java converts.
Anything I have tried to use Mono for has not worked. Maybe there is a subset of of .net stuff for which Mono works perfectly, but I do not think we should say that .Net or Silverlight are cross platform based on an incomplete Mono implementation.
In my experience it's always been the opposite: C# guys have always looked down on Java folks. And rightfully so: the language itself is nicer, the standard library is much nicer, and the CLR+CIL are vastly superior to JVM, especially in memory management department.