Reading this didn’t impress me massively, and not only because it’s a reheated blog post. Don’t get me wrong, the Mono team has done some superb work, but it’s really not ready for primetime. Miguel does a phenomenal job of cheerleading, but let’s take a look at this particular example. That’s not an industry standard benchmark they’re running there, it’s some code on some guy’s blog. It’s quite a nice and interesting blog, but it’s nowhere close to the mainstream.
Sadly, where Mono still falls down is meat and potatoes issues. Look at the number of patches the Ubuntu team need to make to each release before they’re happy packaging it. Look at the weird behaviour problems that the Castle team discuss on their mailing lists (e.g. why on earth does Mono 1.9 believe it can convert from a string to an interface? Don’t they have a regression test for that?). Worst of the lot, however, has to be the garbage collector.
Getting the garbage collector wrong is second only to getting the compiler wrong. People won’t understand what the problem is, but they’ll suffer when it doesn’t work right. Mono currently uses the Boehm garbage collector, which is a non-compacting, conservative C++ garbage collector. If you use vanilla .NET, you don’t need to know about the garbage collector for the most part (unless you’re doing stupid things with finalizers), however, if you’re running on mono, the same program that run fine on .NET can give you nonsense like this: http://www.mail-archive.com/mono-list@lists.ximian.com/msg22436.html. (Incidentally, the suggested remedy is a sticking-plaster over a sword wound.)
At the moment, the only real solution to this problem is to use allocation patterns that the Boehm GC likes, which is ridiculous to anyone who has stopped worrying about memory fragmentation for the last five years. In fairness, the Mono Project is planning to address this at some point towards the end of the year. Then all I’ll be worried about is their quality problems.
Colour Coding 