It seems the comments area here is full of lots of questions and few answers. Let me try to clear some things up.
Lets start with how it currently works...
When you create an application or website in C#,F#,VB.NET or any other .NET language you are not really 'compiling' it per se to native code, you are compiling it to an intermediate language called IL - very much like Java byte code. When your application or website is run for the first time the .NET runtime converts this code to native code on the local computer and then caches this binary and officially compiled native version of your code. The result is, the first time you run your app or a section of the code there is a small performance hit while the .NET runtime converts your code to native. Let me be perfectly clear, this is a one time thing - a first time thing. Once you have gotten past that every subsequent run is going to be as fast as other native code. (Why is it not as fast as something written in c or c++ you may ask - because there are other things the .net runtime is providing for you like garbage collection, but that is a whole other talk)
So how is this different?
This preview allows you to skip this JIT process and image caching process altogether. This is first targeted for Windows store apps, when you would first run it on your machine it was slow on first launch because all this extra work was being done. Microsoft decided they could take the server side resources they had and run this JIT and imaging process ahead of time and when someone downloads and installs your app - this work was already done and first launch would be faster - as much as 60% faster. There are also lots of changes under the hood to make this all work better - Andrew Pardoe is on this comment thread further down and mentioned things like a refactored runtime, static-optimized libraries, static marshalling all combining for performance wins.
Does this mean I can build apps for Unix with C#
No, Mono is still the best way to do that
Can I build simple console apps with this and deploy to machines without the .NET runtime?
No, right now this is only available for Windows Store apps. Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime.
Will this make my app run faster?
Starting up, yes. Normal operation, probably not. .NET runtime and jitter have been around a long time and they are impressively efficient and fast. This includes some tweaks to parts of the runtime but don't expect to see your text file processing app go from 10 seconds to 2 or something like that.
When I read the OP, I was tempted to
scream about bad writing due to lack
of context, undefined terminology, and
general lack of explanation, not nearly
the first time I was tempted to scream
at Microsoft's technical writing abilities.
Your post provided essentially everything
that was missing.
Windows Store Apps are what was once called 'Metro' apps and now termed 'Modern' apps. They are essentially Microsoft's version of apps from iOS app store or Google Play store but focused on Windows 8 tablet and desktops (and as of today, the same apps you develop for these environments can also work on Windows Phone and XBOX One)
In the past if you were writing a client side or 'desktop' app for Windows you used C++ and MFC or a .NET language with Windows Forms or WPF (or lots of other options) to build that experience. Going forward Microsoft would prefer you build using this new model they are calling Windows Store apps. Along with that comes a set of rules and explicit declarations about what your app will do (much like we have on Android or iOS). This should in theory limit the number of crapware that exists, though that remains to be seen.
Jitter is a term we often use for a program that does the JIT work, JIT is an acronym for Just In Time which in context means Just In Time Compiler; it runs just before the code is needed. You have a program with 10K lines of code but the command you just sent the program only invokes 500 lines - a jitter or Just in time compiler will only convert the code that is actually needs to perform the operation you requested (thus performing faster).
Technically JIT may run along with the execution, profile and later replace the code, i.e. start on interpreter, run a bit, compile. JITting is far more complex than "running before the code is needed", technically it can even deoptimize some code and then optimize it better.
How good/reliable is Mono on Linux now? If I knew for sure that people are actually using Mono on Linux robustly and with good performance I would ditch the JVM - as a language/runtime .Net is so much better...
In the OpenSimulator open-source cross-platform project we've been using C# on Mono for over 6 years for a server-side application with extremely high concurrency. From this perspective, recent releases of Mono have definitely increased in reliability. Mono 3.2 onwards is particularly good and it's very rare now, if it at all, that problems we have on the project can be traced back to issues with the Mono VM or the associated SDK.
We haven't done many systematic performance comparisons. However, it seems to be the case that whilst Mono still performs worse than .NET in a few areas (e.g. loading new AppDomains), in general there isn't a significant performance difference between running OpenSimulator on Mono and on Windows.
.NET is not a language, presumably you're referring to C# vs. Java? C# may have the upper hand over Java currently, but Java 8 is a very good sign from Oracle that they're finally willing to push the language forward, which down the road may not necessarily mean C# > Java.
As for .NET being so much better than the JVM, that's not a factual statement ;-) Certainly the JVM, with Clojure, Scala, Kotlin, Ceylon, Groovy, JRuby, etc. running on it, has proven the JVM to be a pretty awesome environment for emerging languages, while the CLR has proven to, not surprisngly, be an awesome environment for Microsoft backed projects.
If you're tied to Linux and Mono isn't a viable solution, why not try one of the above Java alternates?? JVM is a kickass dev environment these days if you're able to break away from Java...
FWIW, last time I tried Mono (a couple of years ago) it was quite impressive, particularly the IDE, incredibly responsive. The biggest drawback was the feature lag between latest and greatest from .NET side of the fence.
How good is Mono - Unity3D is based on it and I have not heard anyone complain that the thousands of games built with it (including some of the most popular ever on iOS and Android) are having performance issues because of the underlying architecture.
> Can I build simple console apps with this and deploy to machines without the .NET runtime?
> No
Darn. I was hopeful that this would help us run .NET applications in Wine by eliminating the need for the full VM, but it appears not.
> Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime.
Well, or a Unix machine trying to run Windows apps in Wine. We are (well, one single dev is, really) still trying to get Mono to work for us, but it's a very long road to get the missing APIs and VM features in place.
Lets start with how it currently works...
When you create an application or website in C#,F#,VB.NET or any other .NET language you are not really 'compiling' it per se to native code, you are compiling it to an intermediate language called IL - very much like Java byte code. When your application or website is run for the first time the .NET runtime converts this code to native code on the local computer and then caches this binary and officially compiled native version of your code. The result is, the first time you run your app or a section of the code there is a small performance hit while the .NET runtime converts your code to native. Let me be perfectly clear, this is a one time thing - a first time thing. Once you have gotten past that every subsequent run is going to be as fast as other native code. (Why is it not as fast as something written in c or c++ you may ask - because there are other things the .net runtime is providing for you like garbage collection, but that is a whole other talk)
So how is this different?
This preview allows you to skip this JIT process and image caching process altogether. This is first targeted for Windows store apps, when you would first run it on your machine it was slow on first launch because all this extra work was being done. Microsoft decided they could take the server side resources they had and run this JIT and imaging process ahead of time and when someone downloads and installs your app - this work was already done and first launch would be faster - as much as 60% faster. There are also lots of changes under the hood to make this all work better - Andrew Pardoe is on this comment thread further down and mentioned things like a refactored runtime, static-optimized libraries, static marshalling all combining for performance wins.
Does this mean I can build apps for Unix with C#
No, Mono is still the best way to do that
Can I build simple console apps with this and deploy to machines without the .NET runtime?
No, right now this is only available for Windows Store apps. Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime.
Will this make my app run faster?
Starting up, yes. Normal operation, probably not. .NET runtime and jitter have been around a long time and they are impressively efficient and fast. This includes some tweaks to parts of the runtime but don't expect to see your text file processing app go from 10 seconds to 2 or something like that.
Will this help me pick up chicks?
Depends.