> started afresh with all of Java's learned lessons taken into account

I don't think that's really historically accurate. Java and C# were pretty similar back in 2002. The .NET team was more willing to add complexity and occasionally make breaking changes, like generics in CLR 2.0.

That's not historically accurate either. The .Net team was more willing to break things because in 2002 they had their 1.0 release. By then Java had already lived through 6 years of very aggressive presence in the marketplace, with lots of legacy code already in the wild. The only legacy MS had to worry about was COM, which had its own compatibility wrappers that were not fundamentally intrinsic to the CLR.

So .Net had the advantage of coming years after Java had shown what it could be done (or not, see browser applets) from a technological and commercial point of view, AND quite a few years of development without worrying about backward compatibility.

I'm not saying Sun developers were not slow (they were), but they clearly had a much more "entrenched" position, with all that it entails.

The JVM is much more sophisticated than the CLR. Its GCs and JIT are many, many years ahead of the CLR's.

It's not that simple. The CLR has a different feature set to the JVM; or rather, it has a feature superset. If you run Java-like code on the CLR, I would expect it to not be as fast or have as high GC throughput as Hotspot, especially if the Java code has been tuned to Hotspot - there are particular fast paths for certain operations that kick in, where if your code is a little bit too far from the optimized idiom, you end up 3-5x slower. For regular code, I wouldn't expect a big gap between CLR and JVM; a lot of Java code is dominated by pointer chasing because the primary tool of abstraction is a heap-allocated object. C# written in the same way will be bottlenecked in similar ways on cache misses, TLB misses, etc.

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.

> it has a feature superset.

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

Graal/Truffle looks lot like DLR. Are they similiar ?

I assume their purpose is similar, but they are really a framework for building very sophisticated JITs -- much more than HotSpot's current optimizing JIT, which is state-of-the-art -- with user-controlled code generation. The CLR has a very primitive JIT to begin with. So while the purpose might be similar, Graal/Truffle represent the future of JITs, while DLR is just a framework that helps implementing dynamic languages for the CLR.

Minor correction: what I said about a similar purpose is true for Truffle. Graal is a general-purpose, optionally-user-controlled JIT, that can (and probably will) be used to JIT Java bytecode in addition to Truffle AST nodes. So it's basically just Hot Spot's next-gen optimizing JIT compiler.

Do you have a blog post or some external site that you could link to for more information about the JVM vs. CLR? It'd be much appreciated

That's a really helpful review of reasons to consider CLR. Thanks.

I'll just direct you to the first reply on Stackoverflow here: https://stackoverflow.com/questions/453610/javas-virtual-mac...

Most of the things in that answer says are simply irrelevant.

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

The CLR offers a lot of functionality that the JVM doesn't (see Someone123's comment) - which in my opinion makes is it a lot more compelling - so in that way it is more sophisticated than the JVM.

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.

> The CLR offers a lot of functionality that the JVM doesn't (see Someone123's comment)

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

That really isn't true. Perhaps 5 years ago it was but not now.

Now more than ever. HotSpot has undergone some revolutionary changes in the past few years -- from the G1 GC through tiered optimizing compilation and all the way to Java Flight Recorder -- while the CLR mostly added some user-facing features with little internal progress other than RyuJIT, which is maybe comparable to HotSpot's C2 JIT circa 2005 or so. Not to mention the awesome work done on Graal now, HotSpot's next-gen JIT, which is another very big leap forward.

So, why would a Mac user develop in it, instead of in a Windows (virtual) machine?

How would .NET compare to Apple's native environment?

I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?

I mean, Java never really caught on with the Mac user base.

One advantage is developing server-side .NET apps without the need of a Windows VM, with the aid of regular Unix tools in your regular dev environment. That's a win in my book.

But a cross-platform CLR opens up some possibilities even for desktop or CLI apps. The wealth of the .NET ecosystem is compelling.

> I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?

Well, probably it is better if you have (say) a company full of people who know how to write C# but have never used Swift. And the whole write once run anywhere thing is nice (sure, native apps "feel" better, but if there are no native apps I'd rather have a Java version than nothing).

> I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?

You said it all. The whole point is cross platform development.

People use Swift to develop apps for Apple products. Before Dot.net was made open source, people only used it to develop for Microsoft platforms.

The fact Dot.net is now crossplatform makes it possible for GNU/Linux and Mac users to consider it for development.

So when will Swift be made open-source?

I am not going to make the same mistake twice and be tied down to a language (Objective-C) and private APIs (Cocoa, iOS, etc) which are useless outside of Apple's ivory tower.

I had always thought of C# and Mono as a potential cross-platform solution, but now that .NET is open-source and Microsoft are pushing it hard, even on Linux, it has become a viable one.

I suspect I am not the only Mac->iOS developer who is thinking along these lines.

For mac users, it's probably going to used for web development rather than native apps.

Although there are some good bindings to cocoa to do so.