OSNews

That sounds far too much like spreading a disease to me. Also you should stop kissing robots, they don't need your mono :p

What, and add a bunch of bloat to my app? No thanks. The default system APIs can already add enough of that and, especially in the case of Android apps, they really don't need to be any slower. Write once, run everywhere doesn't really work as well as most people seem to think.

What bloat? Size? Performance? I've found it adds a few MBs to size, but performance isn't really severely impacted.

Start up? Slightly, but you can get around that in well documented ways.

The upside? The Mono JIT is dramatically FASTER than Dalvik. So, no, actually, if anything it makes your app more responsive.

Plus, write once run anywhere was never the intention. The intention is code sharing. Write platform agnostic back end code and write a native front end for Android, iOS, Windows Phone, Windows 8, WPF, and OSX (MonoMac or Silverlight)

.NET is the only platform enabling actual, real world, non made up, cross platform developer productivity.

It'd help if you tried it once in a while.

Using Mono in Android means running two VM alonside each other with lots of marshling between VM, because your .NET application needs to make use of the DalvikVM APIs.

Just code the core of your application in C or C++, and make use of the platform native UI for the best user experience.

As for WP7, just let it die, as WP8 also supports C++.

Have you actually used it and run into these supposed performance problems? Ive used it, and I haven't.




Yeah, no. To do that, you'd still need JNI on Android, and a Cocoa bride on iOS since key APIs are not available as native interfaces.

You're doing the same bridging that Mono does, albeit without the slight double GC perf impact.

Also, nice little pot shot at WP7, but it has over 100,000 apps, and moving forward, C# will still be the majority language (as it is for Windows 8 apps).

Seriously, I don't get the Mono and C# bashing. Sure, maybe if you felt like hurting your productivity enough, you could use C++, but Mono has been proven to work in the real world.

Have you actually used it and run into these supposed performance problems? Ive used it, and I haven't. "

How many devices have you tried it on?

Actually you might find this talk interesting,
http://vimeo.com/43529195




Yeah, no. To do that, you'd still need JNI on Android, and a Cocoa bride on iOS since key APIs are not available as native interfaces.

You're doing the same bridging that Mono does, albeit without the slight double GC perf impact. "

In Android's case JNI is an issue, but not as much as with Mono.

See Andreia's talk, there are some exposed APIs that go multiple times between VMs.

In iOS there is no marshalling happening.



In Germany, the only person I've seen carrying a WP7 mobile outside a store, was a guy I've met that works for a startup that develops WP7 games.



Don't take it wrongly. Personally my only issue is that Mono/C# is promoted as the only way to achieve portability of native application across mobile platforms, when actually other solutions do exist, depending on what platforms are valuable to target.

So, how is a "faster VM than Dalvik" relevant to a technology for writing apps on iOS devices using a Java-to-Obj-C translator?

Im pretty sure you know how to read.

Meanwhile & pushing aside prejudices, the facts seem to be that ~Mono is the way which quite possibly gives most straightforward multi-platform capabilities with nice performance (adequate for that most demanding category: games), and numerous multi-platform examples in appstores - some of them quite high-profile (Bastion, for example - Xbox, Windows, iOS, OSX, Linux Humble Bundle)

http://monogame.codeplex.com/

Edited 2012-09-14 05:48 UTC

And I thought that would be C and C++.

Well I did put some emphasis on most straightforward there :p (broadly speaking, also how ~XNA is a quite accessible path)

Most portable example spacechem
Linux (!)
Windows
Mac
iPad
Android Tablets
Build on mono (While I agree that the game is not graphic intensive, it is a great example for game with mono )

or switch to Google Go.

Go would certainly be welcome. It would even make a sort of sense.

Except that Go does not seem to be that used by Google.

It is only part of Google App Engine, because the Go team is doing this work, not the Google App Engine team.

For me it appears to be a political decision not to support Go on Android, since the Go team has Go builds for Android.

Of course. It is already possible to use Go on Android. The "sorta sensible" part is really just that Go is also a "Google" project. Of course, I don't expect Go to become standard, but after doing some Android dev. I wouldn't mind something a bit less verbose.

Actually, I think that interpreted languages sort of make more sense for mobile phones, due to the large amount of SoCs that apps will have to run on.

Apple's native code approach only works because there only is a handful of devices to target, with similar underlying hardware.

Very true. JIT compilers are good enough, and an intermediary bite code ensures architecture agnosticism