As somebody who quite enjoys C#, this is pretty awesome news. This means that with the same language, I can write:
* A Mac app
* An iOS app
* An Android app
* A Windows Phone app
* Desktop apps on Linux
* Desktop apps on Windows
* XBox 360 games
* A production-level website
* An in-browser applet
* An embedded system (using .NET MF)
Tools to use, in case you aren't aware (like I wasn't, and Googled):
* A Mac app - MonoMac 1.0
* An iOS app - MonoTouch
* An Android app - MonoDroid
* A Windows Phone app - XNA/Silverlight
* Desktop apps on Linux - Mono/GTK#
* Desktop apps on Windows - regular SDKs
* XBox 360 games - XNA
* A production-level website - ASP.net
* An in-browser applet - Silverlight
* An embedded system (using .NET MF)
Interesting to see Mr. DeIcaza's reaction. From publishing flawed benchmarks showing c# as faster then c++ back in the day, to jumping with joy to see that an open source project is suffering setbacks. Published on the Gnome com channels too.
c# is a nice language, but not a lingua franca. Mono is at best controversial in the oss world, the iOs app gallery is damning the platform by faint praise and Mono on Android does not exist.
It was only flawed in that I compared C# with SIMD with plain C. But the point was to give a flavor of what our SIMD extensions could do.
It would be great to redo the tests, now that we use LLVM as our optimizing compiler, and now that we have an option to disable array bounds checking altogether for speed junkies.
Other than the GC intervening and perhaps some extra fine tuning requires for inlining, with LLVM/SIMD/UnsafeArrays we really should not be any different than C++/LLVM.
Does it let you write for all those platforms with the same language calling the same API? I'm not familiar with C#/Mono besides hearing news about them periodically. If I have to rewrite my code to use a different API for each, it might as well be a different language, since it's the rewriting part (or lack thereof) that's important to me. But if I write once and run everywhere, C#/Mono might be kind of compelling.
It depends by what you mean by API - it's not a "Write Once, Run Anywhere" UI framework, because you wouldn't want that anyways: an Android app should work differently than an iOS app, full stop.
However, everything else does work 95% the same - how you access files / databases, your business logic, all of the non-UI libraries are both consistent, and work really well.
Isn't the same thing possible with almost any language?
Of course this is the case for C/C++. And basically all other native languages for systems where you have some libc-like interface. And then there is Java which should also run just everywhere (I don't know about Xbox360, though). And basically all other dynamic languages which have some native implementation would also work just everywhere. Most dynamic languages also have some sort of GUI framework, sometimes a common one for several systems, sometimes a separate one for each system. And even if not, most languages still allow somehow to just use the system GUI by using the native C interface.
And if you thing about LLVM, you can make almost every language work anywhere also, even if you really only have JavaScript, JVM, .NET or whatever available. (Actually, I haven't really looked at LLVM->JVM/.NET translators yet but I am quite sure that this is doable and probably also already done.)
It isn't about the language in this case, it's more about the implementation of a consistent framework. The GUI will obviously change from platform to platform, but the .NET framework (for the most part) works on all of those platforms. That's a pretty big group of patterns and reusable idioms.
Java is also a no-no on iOS devices due to its JIT model. The .NET stack gets around this by using AOT compilation, so the entire .app is native code yielded from the JIT process (as I understand it). No reason something similar couldn't be done for Java, but as far as I know, it hasn't been.
Developer experience from top to bottom is the win here, I think.
