With the open sourcing of .NET, I wonder how far they've gone. Is it the exact same runtime used on Windows, now fully open sourced like the JVM?
Was the entire .NET platform open sourced, or just a subset?
The entire *server* stack - i.e. everything you need to run a .NET server application. They have even created a small-footprint webserver Kestrel for Linux based on libuv. The reason for libuv actually touches on a very important aspect/advantage of modern .NET (and to some extent, Windows Server) . More on that below.
Doesn't .NET require IIS to run web apps?
No. You have *always* been able to just self-host the ASP.NET bits. However, MS have taken it a step further and completely separated out the bits of the pipeline so that you can pick and choose. For a long time there have been plugins for Apache httpd and others that would allow you to run Mono. Those will work fine regardless of whether ASP.NET is provided by Mono or MS. Kremel mentioned above, but you can use any other way. ASP.NET vNext is "pluggable".
How will you run a .NET web app on Linux?
curl -sSL https://raw.githubusercontent.... | sh && source ~/.kre/kvm/kvm.sh
In the Java world, the entire platform and runtimes are open source.
In the .NET world, the entire platform and runtimes are open source, and the platform specification is governed by international standards organizations (ECMA and ISO).
Microsoft grants patent licenses for anyone who wants to create implementations of the specifications, and Microsoft *specifically* does not require paid testing suites and they do NOT assert that using the APIs constitutes copyright infringement.
And now for some reflections on the differences: Microsofts stack - especially with the latest .NET and Windows Runtime - have grown to become completely focused on asynchronous programming. Windows (the NT line) with the "overlapped IO" available from the initial version always had a very high-performing "completion" oriented async model for all types of IO. While this model could yield much better scalability, to leverage it you had to program in a "callback" style that were often at odds on how you think about a problem (sequentially) as well as poor match for constructs such as exception handling, looping/branching etc.
With C# 5.0 (and the equivalent VB.NET) async became an integrated feature of the language. This is not about smart synchronization primitives, multithreading or similar "low level" concepts. This is aboy having a language that effortlessly allows a programmer to express a sequential problem in a way that allow asynchronous processing all the way down to the system level where overlapped IO will be used. Without invading the way the solution is expressed.
This is huge. I am aware of only one other ecosystem that does something similar: node.js. Python has the capability, but there's no ecosystem built around it where the capability is the default way to design libraries and APIs.
In terms of enabling and supporting async programming style, C#, .NET (and F#) is the most mature option out there, along with the "new" kid node.js.
Java only recently acquired the ability to process web requests asynchronously (yielding the thread to process other requests) - but the language and APIs make it exceedingly hard to leverage this capability for anything useful. If you look up articles for how to do async in Java you will notice a strange tendency to "do nothing" while waiting for an synchronous operation complete. If you cannot do anything useful in the meantime - there really is no point.
In .NET I can follow a few basic rules: Mark WebAPI methods / MVC actions with async, return Task<T> instead of some type T and use await whenever waiting for something like a network request, database query, file IO etc. Then ALL of the processing will be asynchronous all the way down to where asynchronous capabilities of the underlying operating system is used. No multi-threading just to wait for completion. Much less overhead, and much easier tuning of the application (you generally do not need to compensate for IO blocking by spawning more threads).
It is going to be interesting to see how the platforms stack up when on equal footing. My bet is that even on Linux it will be *much* easier writing truly scaleable applications with .NET compared to Java, Ruby, PHP etc.