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.
I hate to bring this up but, as I have been spending more time hacking on open source Mono projects I can't help but ask what the legal future for Mono is currently (last I heard they where working on splitting out the possibly patented code). Does anyone have any input on this?
1. Code in Mono that implements things covered by EMCA/ISO standards. These have about the same legal risk as any other EMCA/ISO programming languages and libraries.
2. Code in Mono that covers Windows-specific things, like WinForms. This is your highest risk area, although even in these areas the risk is probably pretty low. That's because Microsoft patents would cover the particular way Microsoft did these things. Mono's independent cloning of the functionality is likely to have done them a different way. If you want to be maximally safe, don't use these parts of Mono. Use GTK#, for instance, for your GUI stuff. (That runs on Windows, BTW, if you want your Mono app to run on Windows).
3. Code in Mono that covers things not in the ECMA/ISO standard, but not specific to Windows. This would cover things like libraries developed after the current rev of the standard, and such. Most of these provide functionality that exists in most other language ecosystems, such as Python, Ruby, Perl, and so on. If Microsoft has patents in these areas, they are as likely to cover Python, Ruby, etc., as they are to cover Mono.
Microsoft has been known to encourage the Mono developers. That greatly weakens any case they would have against Mono.
Bottom line: it's about legally as risky as the other languages and ecosystems that would be its competitors, especially if you stay away from things like WinForms. If you would feel legally comfortable doing something in Ruby or Python or Perl, doing the same thing in Mono should be fine.
Makes me wonder whether Cocotron's AppKit can be reused for other platforms - Windows, Linux, etc. with MonoMac?
The ClozureCL guys are doing something like this - their GUI is written with AppKit/Foundation, and using Cocotron they have some version working on Widndows.
Just to be clear (please correct me if I am wrong), this is wrappers for the Cocoa API so you can write Cocoa apps in C#. It doesn't provide cross platform compatibility for apps since there's no UI framework compatibility.
