Any mono users here also familiar with .net? how compatible are they? What works and what doesn't? What sort of applications is mono best suited for (server backend? desktop? mobile? web front end? systems programming?)
We are a predominantly Unix/Linux shop that has taken over a .NET project. We are doing builds with Hudson and Mono for a web application that gets deployed to IIS. Overall, everything works but there have been a few surprises.
One surprise was that debugging is hard because Mono uses a different format for debugging symbols. This means we get tracebacks with no line numbers.
The second surprise is that we have to munge resulting executables with corflags.exe to force them to run in 32-bit mode on 64-bit boxes where there are library dependencies that keep them from being 64-bit clean.
We are trying to develop using MonoDevelop but there are some weird incompatibilities with the SQL Server client library. These are not insurmountable, but it has been a hassle.
The other hassle is that MonoDevelop is terribly slow. It does not appear to be able to do incremental compiles so any change to the project results in a recompile of the entire project.
Awesome. Thank you. I will do that. I do suspect that there might be changes to my project structure that would make things easier under MonoDevelop.
I should have made clear that other than these little annoyances, we love MonoDevelop. I certainly prefer using it within my standard Linux and OS X environments over figuring out what I need to click on in Visual Studio to get anything done.
Mono's ASP.NET or MVC or Manos are all running natively compiled code, so for equivalent tasks they should all be faster than interpreted languages.
Whether this matters or not will depend on the what your application is doing and how many users you have. For example, if your application is database bound or file system bound you wont likely notice much of a difference as the time you spend running CIL code or interpreted code is a small portion of your overall CPU consumption.
With Mono 2.8 we significantly improved Mono's web server scalability, but this will not matter if your application does not use or require more than a handful of CPUs. But is incredibly useful for people that are scaling servers under load.
How is your team keeping such a fast pace? Do you get a lot of assistance or documentation for Microsoft. Your rate of feature parity with the MS releases is impressive.
Well, we prioritize what developers need using our Moma tool (this tool does a static analysis of your executables and libraries and informs us what APIs are the most important to get).
In addition, a big help was the fact that Microsoft open sourced large swats of code in this release (DLR, MWF, OData, LINQ, and a bunch more).
I haven't done any benchmarking and I don't use RoR or PHP much, but as a data point, the Mono stuff running under Apache seems slower than similar Java code running under Tomcat.
I've used Mono to run some of my C# server applications on a linux box. I basically copied over the exe/dll files, ran it, and it worked. In a few cases I had to fix some platform-specific things (like hard-coding the directory separator), but all the core, standard APIs worked exactly like they did on windows. In most cases I was actually able to compile my applications from source using Mono's build tools without any modification, despite the fact that I authored them in Visual Studio so I didn't have a makefile (Mono provides a handy tool that reads VS project files). The biggest question mark is in terms of behavior and performance - it's possible that you could end up with a pure .NET application that happens to depend on a quirk in the Windows thread scheduler, or use a feature that happens to perform really badly on Linux due to API constraints (asynchronous IO in .NET is a good example of this; it's designed around Windows' IO Completion Port mechanism and there isn't a good analogue on Linux).
For desktop/mobile .NET applications, it's going to be more difficult to run them on Mono since they probably rely on APIs that aren't part of the core .NET standards, like Windows Forms. Mono has implementations of some of those APIs, but they aren't complete, so those apps are going to be less likely to work without modification. A lot of desktop .NET applications also call directly into Win32 for whatever reason, so that won't work on Linux. To help address this problem, the Mono guys provide a tool that can scan .NET applications for uses of APIs/techniques that don't work in Mono, and lists out the problems for you so that you can fix them.
Anyway, from my perspective, your best bet with Mono is server and mobile applications. Server, because you have two relatively solid server stacks to choose from (Microsoft .NET + ASP.net and Mono .NET + ASP.net) and you can develop in Visual Studio or MonoDevelop while running your deployed code on commodity hardware. However, it's worth pointing out that the Microsoft garbage collector is still a bit more mature than mono's so you might face challenges getting high performance out of your apps on Linux, since your ASP.net processes will be long-lived. Mobile, because Microsoft goes out of their way to make .NET development on their mobile platforms relatively accessible, and the Mono team has made great efforts to let people build native-feeling Android and iPhone apps in C#. In both cases you won't be able to write-once-run-anywhere, but you'll be able to write your core application logic once in C# and then do mobile platform specific UI development in C# as well.
Great summary post, but I want to add one thing—Mono just got a new garbage collector with the 2.8 release called SGen. SGen is a generational garbage collector with nurseries, a cardtable-based write barrier, a parallel mark and sweep collector (which is not enabled by default right now, but there are instructions on how to enable it).
SGen should show better performance on GC-heavy workloads, a fact demonstrated by the SGen part of http://www.mono-project.com/Release_Notes_Mono_2.8. Also, the LLVM backend can be used for yet-another-JITter, though the garbage collector I think remains SGen/Boehm (not sure on this).
The chart is based on 2.6, the stuff that was added today falls under the "Current Mono Trunk" section.
I'm not sure if the DLR (dynamic language runtime) is fully functional on Mono yet. The DLR is what's used to make IronPython and IronRuby run on the .Net stack. It's embedded into Silverlight, which allows developers to run Python and Ruby in the browser (assuming their users have the Silverlight plugin). Mono has Moonlight, but again, I'm not sure if the DLR is in there.
I personally see C# as an evolutionary next step from Java. That being said, languages like Scala, Clojure, JRuby (which I guess is technically a language implementation) let you get the benefits of Java without all the sucky language parts.
C# is a solid server-side language. I'm not terribly impressed with it for the web, although MVC makes it much better than it used to be (blah, webforms). There's an interesting project that was posted here recently called "Manos de Mono" that offers some variety in the web space [1]
It's also turned out to be a pretty decent mobile development language. You can develop iPhone and Android apps using Mono [2][3], as well as cross-platform games [4][5].
You can use Mono in client-side applications, but I'm not sure how well it works or everything that's involved with using it that way.
One of the nice things about Mono is that it lets you write C# on Unix and Unix-like platforms. For those of us that use C# during the day, it's liberating to be able to use the same language on our Macs at home, or deployed on Linux servers next to our other software.
C# is an evolutionary step from Java, but it gets a bigger one with every version. I would say it has diverged further from Java than Scala. I think it's become a really interesting language. Somewhat surprisingly. It seems the people around Anders Hejlsberg are somewhat of an aberration within Microsoft considering how slow other groups move.
Anyway, the most interesting feature in .NET is that its memory consumption is about half that of Java on an average application. Sometimes more. Memory constraints are what bothers me most with the other platforms I use, particularly in a hosted environment where doubling memory often means doubling overall cost.
I don't find it surprising at all - when you look at some of the people MS have working for them, not only Anders Hejlsberg but Simon Peyton-Jones, Don Syme and others. They've got some world-class talent in language design and nearly unlimited resources. ML in the guise of F# in the hands of every Visual Studio user, any of whom can use it without incurring the ire of the PHB 'cos "it's Microsoft". These are great days, my friend!
I would say it has diverged further from Java than Scala.
Could you please elaborate why do you think so?
(I am just interested to hear some toughts from someone who has experience with all three languages - Java, C# and Scala. I know Java and C#, but I did not yet have time to learn Scala).
I'm not doing any actual work with Scala either. I read Programming in Scala a while back and played with it some but not much more. What I had in mind when I said C# diverges more was Linq.
It does apply to Mono as well. I haven't done a detailed comparison, just some ad hoc tests. The reason why memory consumption is so much lower is not an implementation detail. It's because .NET knows structured value types (struct in C#) and hence uses way way fewer pointers than all JVM based languages.
C# as a language and .NET as a platform both seem pretty powerful but there's no way in hell I'd build anything non-trivial on a Microsoft stack. I don't have anything new to add to the argument but I'm just not comfortable with the degree of faith people like Miguel seem willing to put in MS and some of his more recent defenses of them in particular just sound like denial
I'll take the JVM with all its warts and Scala or Clojure over C# no matter how nice it is.
One nice thing about the HN crowd is that it is for the most part pragmatic, able to quite refreshingly discuss C# as a language without immediately descending into these tired talking points casting Microsoft as patent-wielding bogeyman, etc. This is even more peculiar now that Oracle owns Java and is actually engaging in the kind of behavior that we were supposed to be desperately scared of Microsoft engaging in with .NET any day now.
If you're reflexively injecting off-the-shelf 'be afraid to use it' notes into a conversation where C# is mentioned, and applying a trite pop-psych analysis to Miguel de Icaza to boot, you may want to take a few steps back and ask who is really bringing faith and dogma to the table here. Is there anyone in this crowd who hasn't heard your stated opinion approximately 1,000,000 times, and who wouldn't carefully weigh such considerations before making any production commitments?
I agree that the Oracle acquisition and lawsuit is troubling. I disagree with everything else you've said. Java has an established, vibrant open-source ecosystem. C# does not. Java was the brainchild of a bunch of sincere tech geeks. C# was another cynical MS business ploy. Sun and now Oracle are heavily invested in Linux and other open-source projects. Microsoft has many times described open-source and Linux in particular as its enemies and indulged in a lot of sabre rattling and hints of patent infringements and has fought tooth & nail to stop adoption of Linux and open formats and standards at every possible turn:
Would I be happier if Java were in better hands? Yes. Does that make Mono/C# a reasonable alternative? No chance. If you're tired of hearing these arguments blame Microsoft for making them intrinsic to any discussion of their platform. Technological choices sometimes have ethical implications.
The DLR is fully functional in Mono by virtue of Microsoft having open sourced the entire DLR under the MS-PL and Apache2 licenses, so this release contains the same DLR that you get in .NET 4.0
I agree with your statements about webforms(double blah), I've been working on a fairly signifigant MVC2 project at work and its far better then doing the same in webforms. Microsoft is truly trying to get back into the web game and make it 'cool' to be a web dev on the M$ stack.
That said the community is still lacking. Their are plenty of motivated passionate people but they very often feel like their are just doing it to get a book deal or speaking gigs and not because they care.
There are quirks here and there; I use mono through unity3d, so that informs the things I notice. Specifically interop with unmanaged DLLs is: well, more guesswork than I would like. For instance, Marshal.PtrToStringAnsi (function that creates a .NET string from an unmanaged char* pointer) expects UTF-8 data; best of luck deducing that from the name of the function or the documentation.
Ansi strings in Windows are encoded using the current codepage, which is an OS-level setting depending on the localization settings. Most of the time, in the Western world, it's Windows-1252 Western European / Latin-1. It indicates how string arguments to the Ansi versions of WinAPI functions will be interpreted (ending in A rather than W).
This is the way things have been done on Windows for ages, so I don't think the concept is particularly foreign to people expert enough to need interop with native libraries.
The Mono documentation[1] indicates that Mono uses UTF-8 for all string marhsalling operations, which seems pretty unambiguously documented. It's as if GetACP() returned CP_UTF8.
Right, understood. My particular beef was that the function to create a managed Mono string from a UTF-8 encoded unmanaged string was Marshal.PtrToStringAnsi (which is even more confusing if you are familiar with the Windows string encoding heritage: how should the data be encoded in Mono on Windows? Still as UTF-8, I think counter-intuitively, and differently to Microsoft's own runtime, which will of course expect ANSI).
The problem is simple, this is a design mistake in .NET's API. They designed the Marshal class to suit Windows and Windows only and they only had two choices UCS2/UTF16 encoding which they call "Unicode" and current code page which they call "ANSI".
Adding a new API say PtrFromUtf8 would mean that the code would not run on Windows because all of a sudden we are referencing a method that does not exist on .NET.
So we took the approach of turning "current code page" in Unix to what made sense on Unix: it is UTF8.
In fact, the particular issue of UTF-8 encoding is the oldest bug opened against Mono, not something that we can fix without breaking binary compatibility.
At this point, we value more staying binary compatible with the core libraries than breaking compatibility with the .NET toolchain.
We try to extend Mono in /new/ libraries like Mono.Simd or Mono.Unix where we have complete reign over the API and can still let them run on Windows with the native .NET toolchain.
Whether it was a mistake is rather a matter of perspective: I'm sure the Microsoft folks didn't think it was wrong. But that aside: I realize that it may not have read that way, but I think what Mono does is an elegant solution to an unfortunate problem so I'm not knocking the approach. For something so fundamental (and obtuse), I just found that it was skirted a little too broadly in the docs that I read (I also searched around mailing lists for a while, where this particular topic seems to have been an intermittent source of confusion over the years).
Nonetheless, thank you for taking the time to address my observation.
I switched from .Net to Mono/linux for a web application and almost everything worked right away. Most of the differences I found where because of Linux: case sensitive file names and file encodings with non ascii characters.
Is there a packaged build of MoMa for 2.8 available? I couldn't get our code base working in 2.6 due to a few compatibility issues, but a quick once over the compatibility page looks like those issues may be resolved. Here's looking forward to testing a lot of cross platform code!
Would be nice to dish and get real insider info.