There seems to be some discussion about Mono's performance, and I wanted to address that.<p>The default configuration for Mono is a blend of fast startup, and decent code speed. You can tune these parameters depending on your use profile which can range all the way from: startup is the most important factor to high performing code at any cost.<p>In general the language Shootout compares the default configuration of Mono vs all kinds of other configurations.<p>Those interested in Mono for High Performance Computing will be interested in some options:<p>* LLVM: passing the --llvm flag to Mono instructs Mono to pass the code to the LLVM optimizing compiler, and will run your program through every heavy weight optimization that LLVM supports. This comes at the price of slow startup times (much slower), but for HPC or server loads, the extra time it takes to JIT is worth it.<p>* Unsafe mode. If you have battle tested your application and you never get an IndexOutOfRange exception, you can instruct Mono to never perform array-bounds checking. Arrays bounds checking basically ensures that every time you do array [i] that the value of "i" is within the range 0..array.Length. This can be expensive, but makes your program safe.<p>Passing -O=unsafe basically gives you the same semantics of C or C++: you know what you are doing, and you really are not too much into safety.<p>With LLVM + unsafe access, as far as the LLVM optimizer is concerned, there is really no difference between C# and C++ code, and you will get the same performance for compute intensive tasks. The only case where the dynamic of performance would come into play is when the garbage collector kicks-in, vs manual memory management. That in general depends a lot on the kind of app you are building. Many HPC applications preallocate all of their memory before large computations anyways, so in those apps the GC makes no difference.<p>The third optimization is to use Mono's new garbage collector, which gives in general a nice 2x performance boost to memory intensive applications. In general, the new GC is great for memory intensive applications, while the old one is better for pure computational applications that are not memory allocation bound.<p>With Mono 3.0, we also have implemented the inlining attribute (new in NET 4.5), which developers can use to force a function to be inlined, something that before was entirely based on JIT heuristics.<p>And of course, you can tune the individual Mono or LLVM optimization options.
<i>“But even if Microsoft started to deemphasize .NET, I believe .NET would endure because the community will continue to fill in the gaps so that the ecosystem abides.”</i><p>Is .NET really that great a platform that these OSS devs will continue to support and improve it after it's been abandoned by Microsoft?<p>Not saying that's going to happen—but as a .NET dev myself, I'm curious. If it did go that way, I think my only motivation to continue using .NET would be that I don't want to rewrite years worth of code.
When I evaluated .Net for my database client I saw a nonportable Java. When I was working on a structural mechanics code I had performance considerations that were not met. The former niche of .Net was that it could painlessness interface with Microsoft technologies, without MS's love, support and their technology why would anybody use .Net?
<i>"There’s also this perception that with Windows 8, the Windows team is trying its best to relegate .NET into the dustbin of legacy platforms"</i><p>I haven't heard that anywhere. They are tightening the APIs for security and there is the usual rebranding (Silverlight apparently is out) together with the addition of 'our new things are brilliant, unlike the things that we, lasy year, called our new brilliant things', but AFAIK, Microsoft bet and is still betting heavily on .NET.<p>Anybody know what this statement is based on?
Xamarin appear to be pushing big time the cross platform abilities of C# now. It <i>is</i> possible to have your business logic shared between Windows desktop, WinRT, iOS, Android, web apps etc, with a thin native UI layer on top.
What it would take for me to consider .NET/C# more often, is easier interop with C. I really like the way Golang does it, I know P/Invoke isn't terribly hard, but it's still messy and you have to muck around with attributes and annotations. In Golang I did some interop by simply pasting lines and names of header files around. That's a lot more convenient than having to decide how to layout a struct, at least that was my impression when I looked into it.
Mono documentation is very sparse as well, they basically tell you to just look for the msdn docs, which splits your efforts up and makes you uneasy whether you'll run into Mono specific things. (which there are)
This is one of the areas that open-source shines: when a core technology that has a passionate following is no longer supported, that passionate following can take on the project themselves and continue.
.Net not equals C#.
C# is great, but .Net sucks.
limited ecosystem, no one want to implement good open soure project on .net stack. no similar level project like JBoss.
Anyone who bought into Microsoft's Proprietary .Net platform deserves what's happening to them now. Anyone who buys into Microsoft's Windows 8, Windows RT, Windows Phone 8 ninsense is just plain braindead.<p>But some people never learn :-)