Mono 3.2
mono-project.com
mono-project.com
I suspect that C#/Mono has become the de-facto second development language/environment for iOS thanks to Unity3D (an irony that doesn't escape me). It's certainly what all the iOS games programmers I know personally use (and I know a lot).
Wikipedia have Unity down as having over 1 million developers developing for iOS, Android, Windows, Blackberry 10, OS X, Linux, web browsers, Flash, PlayStation 3, Xbox 360, Windows Phone 8, and Wii U.[2]
Unity themselves claim[3]:
* 2M REGISTERED DEVELOPERS
* 400K MONTHLY ACTIVE DEVELOPERS
* 225M TOTAL WEB PLAYER INSTALLS
* 6.6M EDITOR SESSIONS JUN
XNA is a very basic library to roll your own game engine.
Unity is a game engine that handles scenes, game objects, physics, animations, complex 3d animations and very sophisticated graphics effects all blended together in a powerful IDE.
XNA is a hammer and nails, Unity is a house.
I'm also not happy that Linux is a second class citizen - there is no Xamarin Studio for Linux, the latest version of MonoDevelop is not packaged for Linux, and the latest version of Mono 3.2 is only packaged for Mac as an easy download.
The idea of writing most of my application logic in C# and reusing it on desktop and mobile platforms is appealing, but I don't want to use proprietary libraries like Xamarin.iOS and Xamarin.Android, while on the desktop I don't know how well supported GTK# and Qyoto are.
Mono never succeeded on Linux because it always felt like a second-class citizen on the desktop and it's basically useless for server-side apps, an area where the Linux ecosystem shines. Python is popular on Linux because Python can be used for everything, including desktop apps, including server-side, including Gimp plugins. Out of all C/C++ alternatives, Python has the best bindings available. Java is also popular amongst Linux folks, because Java has always been first-class on Unix.
If anything, it's Microsoft's fault. They were late in acknowledging Mono, they were late in giving a patents grant for the ECMA standards, they are always late in updating those ECMA standards (e.g. Async is not in the current version), they failed to make .NET cross-platform, they failed in fostering an open-source .NET community, they failed at PR and they continually disappoint by attacking Android or other projects with patents infringement threats (did you know that Microsoft makes more money from patents licensing to Android than from Windows Phone?)
Err, I'm not sure where you were from 2005 to 2009...
There were apps like Tomboy that were included in GNOME releases that were 100% written in C# and run by Mono. GTK# was one of the most complete bindings ever written for GNOME/GTK.
If you've ever written a GObject or GTK based app you would know its not easy to do in C. With GTK#, you could build something very quick with a modern virtual machine, framework bindings for pretty much the entire free desktop stack (they automatically generated them and kept them up to date with every release), high level language and IDE with great syntax highlighting and autocomplete.
What did happen was a massive irrational backlash against C# by neckbeards that ended with it being kicked out of GNOME core and off the debian and ubuntu install CD's, all because they saw Microsoft name against the standard, didn't agree with the patents (a fact of life when you build software) and bricked themselves.
Also, Mono apps were replaced in Ubuntu/Debian because of Mono's large footprint, both in memory and in disk usage (until recently, Ubuntu has been constrained for a long time to the size of one CD). Also development died and these distros are distributing by default apps that are actively developed and maintained.
And the IDE support still sucks and the bindings are patchy at best (but admittedly better now because there is only 1 person working on GTK compared to the ten or fifteen who contributed back in the day and they release a lot less).
> Also, Mono apps were replaced in Ubuntu/Debian because of Mono's large footprint, both in memory and in disk usage
Thinly veiled bullshit if you ask me. If they were worried about package sizes, there were a lot of other things (like sample photos, movies, music, Open Office bloat, shipping multiple library versions, etc) that they could have cut back on if they got serious.
Regardless, the FOSS community shot themselves in the foot by jettisoning one of the most complete platforms that actually had decent developer tools.
Java and .NET both have a wide variety of libraries and bindings. I'd say that for many projects, the CLR will likely have the bindings you need.
I believe there was probably a ton of in-fighting at Microsoft regarding .NET's cross-platformness. Microsoft did release an open source version of .NET (Rotor) that ran on Mac OS and FreeBSD. The CLR and BCL in general is not Windows-specific. For the most part, the runtime and core libraries are careful to realise they may operate in other environments. However, I'd imagine the argument of "why make software easier to run on non-Windows, which is a major source of revenue" won out. (After all, Sun put money into Java, which didn't seem to help their revenues, right? And then, when MS decided to adopt Java, Sun cut 'em off. Otherwise, .NET might never have had happened, at least not to the same extent, as MS would have sunk a lot of effort into J++.)
The parts of .NET that are platform-specific are for good reason. Cross-platform UIs, for instance (like Java's), seem to universally suck.
Meanwhile, the Mono guys are close enough to make cross-platform viable for many people. They provide a legitimate "it's not vendor lock-in" excuse. And Microsoft could always buy them if they wanted to get more involved.
The whole ecosystem is Windows only and tightly coupled with Visual Studio. You do not have Maven for example and personally I could never get NuGet to run. Also, before the new generational garbage collector, which was just declared stable, ASP.NET was leaking memory because the old conservative garbage collector had problems with the allocation patterns of ASP.NET. Yes, you could run your fancy app on Linux, but for anything serious you had to restart your servers periodically.
Performance sucks too for ASP.NET apps. It's not acceptable for a compiled and statically typed language to have the same performance as Python, or sometimes even worse. Part of the reason for that is the heaviness of ASP.NET and the IIS coupling that is missing in Mono. But then again, why should that be your problem, when better alternatives for Unix are available?
Also, ever tried debugging / profiling an app in production? Seriously, you have to be slightly masochistic to use Mono on server-side.
Fun fact: .NET's debugging symbols are not a part of ECMA's standards, are not documented and for a long time Mono used its own incompatible format for debugging symbols.
> Microsoft did release an open source version of .NET (Rotor) that ran on Mac OS and FreeBSD
Rotor was never open-source. "Shared source" is not open-source. In fact people that contributed to Mono were warned to not look at Rotor's source-code.
> After all, Sun put money into Java, which didn't seem to help their revenues, right?
Blaming Java somehow for Sun's failure is a logical fallacy. There is no proof that .NET helped Microsoft's bottom line (my gut tells me that it did the opposite). Also, I'm pretty sure Java was a major reason for why Oracle bought Sun and for why Google was also thinking of buying Sun.
> when MS decided to adopt Java, Sun cut 'em off
Microsoft had an explicit agreement with Sun. They broke it by making Visual J++ both source and binary incompatible with Java. This isn't regular "adoption", but rather their usual embrace/extend strategy. Also .NET 1.0 was J++.
> The parts of .NET that are platform-specific are for good reason. Cross-platform UIs, for instance (like Java's), seem to universally suck
That's a poor example. When thinking of cross-platform, I think more about Qt than I think about Swing. Also, platform-specific behaviour has leaked much further than Windows Forms. For example, Mono's implementation of asynchronous sockets suffered for years because System.Net.Sockets was modelled after Windows' kernel and doesn't map cleanly with poll/epoll/kqueue.
Wrong.
>You do not have Maven for example and personally I could never get NuGet to run.
Besides the fact that there are alternatives (and that you don't even need it in the first place), personal competence ---not getting it to run-- is not a valid reason to discard it.
How about being an absolutely terrible method of dependency management? And yet it's the only serious game in town? Ruby has RubyGems. Python has PyPI. Java has Maven (and its mutually compatible friends). Mono has...NuGet. It's still pretty bad, even when you get it to run. Boy-howdy, do I want my projects cluttered with downloaded dependencies in 2013. :-(
Seriously, even today dependency management is the worst part of dealing with .NET. (There are worse parts of Mono, but most people will never run into most of them. I wouldn't if I wasn't trying to bend it to do things it probably shouldn't be bent to do.)
Glad to be enlightened.
> Besides the fact that there are alternatives (and that you don't even need it in the first place)
No, there aren't alternatives and yes, you do need it, as manually managing dependencies is so 1999.
> personal competence ---not getting it to run-- is not a valid reason to discard it
What can I say, the hallmark of any good developer is blaming it on the competence of users, right?
I'm not the only one that experienced pain dude: http://lmgtfy.com/?q=running+nuget+on+linux
Ironic, because then you go to state:
>Mono never succeeded on Linux because it always felt like a second-class citizen on the desktop
Mono had full GTK support. Tons of popular Gnome apps were written in Mono, music apps, photo viewers, desktop search etc. There was nothing "second-class citizen" about it.
It was all about the MS situation and FUD.
>and it's basically useless for server-side apps, an area where the Linux ecosystem shines.
For one, it's based on .NET, has a port of the MVC web framework and everything -- and tons of open source stuff for it. "Basically useless"? The same tech powers 99% of server-side apps on Windows.
And meagre QT support.
> Tons of popular Gnome apps were written in Mono
And very few KDE apps.
> There was nothing "second-class citizen" about it.
Except that it simply didn't belong to half the desktops (i.e. ones running KDE, which might actually account for more than half the deployed Linux desktops, considering it's long been the most popular Enterprise choice).
> The same tech powers 99% of server-side apps on Windows
... where PHP/Python/Java/Ruby are second-class citizens. To each its own, I guess.
So what? It targeted the Gnome desktop. Does it have to catter to every GUI toolkit there is?
>And very few KDE apps.
And no KDE app at all was written with GTK. So what? Mono developers targeted GNOME.
>Except that it simply didn't belong to half the desktops (i.e. ones running KDE, which might actually account for more than half the deployed Linux desktops, considering it's long been the most popular Enterprise choice).
Actually the most popular Enterprise choice has been Gnome for half a decade or more. The only major exception had been SuSE, a distro which languished. RedHat (and Centos), Ubuntu, etc all went for Gnome.
To be a first-class citizen on "the Linux desktop", covering at least both main alternatives is a must.
> Mono developers targeted GNOME.
Thereby renouncing half the desktops.
>Actually the most popular Enterprise choice has been Gnome for half a decade or more
Maybe in the States. In Europe, KDE has long been the most popular choice for large deployments, which is why RedHat and friends still ship it.
And it wasn't really about FUD. As I said, that's only a small loud minority. Both Ubuntu and Debian's core had statements to make about it. You might want to Google it.
Nicely done.
The first kind of thinking is what got us into the second kind of situation.
Enjoy ...Vala.
What's wrong with Vala?
It would appear that with GTK libraries available on Windows and OSX, a port of a Vala app should be trivial. Valac compiles to C and then GCC takes over for the rest of it.
It seems like the most well-known Vala apps are managed in San Francisco by Yorba, however they're only for Linux. http://www.yorba.org/projects/
Any examples of cross-platform apps written in Vala?
Or, the current situation is a vindication of that sort of thinking.
The only concern I would have is that Microsoft might try to crush Xamarin at some point, but I wouldn't count that likely, Mono is their ticket to keep .net from looking like anti-competitive platform lock in.
I wish I could go on but I've had this argument before.
Microsoft is not setting technical direction for Mono, and I expect that there are few (if any) Microsoft employees contributing to the project -- because of conflict of interest and IP concerns. They are very much at arms-length with regards to Mono.
So far as *nix tools being superior - I would agree that they do what they are designed to very well. But don't turn up your nose at C# and the .net framework -- it's quite good, and doesn't have the Java factory factory factory issues.
It isn't. Try developing apps with it. Then compare it with Java or Python. You'll see the light eventually.
> The only concern I would have is that Microsoft might try to crush Xamarin at some point, but I wouldn't count that likely
Microsoft is a beast. They are currently making more money from patents licensing for Android than they are from Windows Phone. Wishful thinking has no place in this world.
That doesn't mean that Mono is any more of a risk than the alternatives. Oracle sued Google for Java, right?
(Installing pango/gtk etc from source really takes the juice out of you.)
First result on Google for building Mono. Download the source, unpack, configure, make install. I've done this on many versions, and it seems to work just fine.
I go at it every few weeks with renewed interest, but at some point I find myself wading through the forums where there is little or no response to questions similar to the ones I have at that moment.
GTK# is what is used to develop Xamarin Studio / MonoDevelop, so it is pretty well supported.
It's their choice if they want to and they've done great service for the community with what they've already done. But if they've changed directions I think they should come out and say it so current and potential future users of the platform know.
In another HN discussion, a person from Xamarin said they didn't have the resources to keep Linux package management up-to-date.
However, they scored $16 million in funding this month, so going forward they certainly do have the resources.
The newest stuff is still 2.10, expect for mac
So, Mono/C# in Chrome? If NaCl/PNaCl becomes available outside the Chrome App Store, that could be pretty exciting -- Mono does an excellent job with AOT performance and mobile-scale memory utilization.
That post is old, but the instructions are still valid.
> I assume the API's that NaCl-exposed have a corresponding set of C# interfaces? How does one write to the browser window, get user input, network I/O, etc?
Unfortunately there is nothing available to expose Pepper interfaces directly to the managed environment that is shipped with this, though it is possible to auto generate bindings and glue code to make it work. What you'll see in the HelloWorld example I linked above is a very manual way of doing this, exposing an internal call that itself just calls directly through the C Pepper interface, effectively allowing Pepper calls from C#.