Alvaro points
out that in the Language Shootout Benchmark Mono comes
in 18th
place compared to Java's 10th place.

We know that Sun's proprietary Java edition (not the open
source one, as that one
is nowhere to
be found yet) is faster than Mono, but I was surprised
that we were so far behind.
So I
looked at the comparison between Java6 and Mono.

Memory usage wise, we mostly come ahead, but in
performance, there were two places where Sun's server VM beat
Mono seriously in performance (5x or more), one is
the regex-dna
test and the other one
is pidigits
test.

The regex test is a test of the regular expression matching
engine in the class libraries, not really a test of the
language or VM performance, but library implementation.
Clearly, our Regex implementation could use some work.

The pidigits test was showing up as 6x better with
Java than with Mono. But the test is basically comparing C#
vs assembly language. In Mono's case it is using
a full
C# implementation of BigInteger while
the Java
version uses the C/assembly
language GMP library that has
been tuned
with hand-coded
assembly language.

I ported
Java's pidigits to C# to also use native GMP, and the results
are promising, we now have a 4.7x speedup and the process size
is one megabyte smaller. I was unable to test the Java
version on my machine, as I could not find the native
"libjgmp" library.

I wonder what the policy is for the language shootout to
use external libraries. If its ok, I should contribute my
port, if its not, the Java test should be rewritten to be a
fully managed implementation.

If you
run all
the tests the gap between Java and Mono goes from 8
places, to 3 places; If you remove the two bad tests (Our
Regex implementation, and the pidigits test) Mono is only one
slot behind Java server; and if you
also account
for memory usage (but still account for all the tests),
Mono comes ahead of Java.

Of course, we got homework to do: why is our Regex
implementation so much slower?

Update: As it turns out, Mario Sopena pointed out
that, another 25% performance improvement can be achieved if
the implementations are similar. The C# sample does a lot
more regex work than the Java implementation does. The
Python implementation has further refinements on the algorithm
that could improve the performance further.

Some Observations

Close to the metal languages are the first tier
(C, C++, D, Pascal, even Eiffel).

Compiled functional languages come next (OCaml,
ML, Haskell, Lisp).

Java and Mono are on the next tier.

A big jump comes next: Erlang, Smalltalk, MzScheme.

Next big jump: Pike, Perl, Python.

Another jump: PHP, Javascript.

Tcl: a class on its own.

Ruby, last one.

There are a few rarities, like Fortran being in the same
tier as Java and Mono, which probably means the tests for
Fortran have not been tuned up, I would expect it to be in the
same tier as C.

Also, am surprised by Ruby being the last on the list,
I expected it to be roughly in the same range
as Python,
so I suspect that the tests for Ruby have not been tuned
either. Update: my readers also point out that Ruby
1.9 will improve things.

Update: I just noticed that Eiffel is on the first
tier, performance wise, but has pretty much all the properties
and features of the third tier (garbage collection, strong
typing, bounds checking). This means that you get the best of
both world with it (and Eiffel's compiler
is now
also open source).

Language Productivity

And of course, at the end of the day, what matters is how
productive you are writing code in a language. The Wikipedia
is powered by PHP, Amazon by lots of Perl and C, Google uses
Python extensively, and the stellar productivity that can be
achieved with Ruby on Rails is hardly matched. So even if
your language is slower than the first few tiers, to many
developers and sites deploying software what matters is
productivity.

Choosing between Mono's C# and Java, both languages being
roughly on the same class, is a function of the libraries that
you use, the ecosystem where the code will be
developed/deployed and to some extent the language.

So even if we have a slow regular expression engine, we
have working closures, iterators, events, the lock and using
statements in the language and LINQ.

Of course, I wish them the best luck (in the end, Mono is a
language-independent VM, and we are just as happy to run C#
code as we are running Java
code, which incidentally, just
reached another
milestone) and we certainly plan on learning from the open
source Java VM source code.

[1] Am tempted to write a post about the mistakes that both
Java closure proposals have. But it seems like it will be a
waste of time, it feels like there is just too much hatred/NIH
towards C# in that camp to make any real progress.

paint-mono
is a port
of Paint.NET. The
only way it could be built in the past was using a development
version of MonoDevelop and there was no way of generating
packages for it.

Since then, MonoDevelop has progressed to the point where
it can generate standard Unix makefiles and generate the
proper scripts, pkg-config files and produce code that
conforms to
the Mono
Application Deployment Guidelines from a Visual Studio
solution.

It is now easier than ever to try Paint.NET on Linux, all
you need is:

I have not spent much time porting
the SystemLayer.dll, but it is enough to access most
features in Paint.NET. A real method-by-method audit needs
to be done for the port to be considered complete though.

We are calling it "Mono Paint" as the authors of Paint.NET
have requested us that we do not use the same name for the
porting effort. The idea is that eventually the port will
merely be a drop-in replacement for the "SystemLayer.dll" the
library where all the OS-specific code is located.

For more details on downloading it, filing bugs, or
tracking the project, see
the paing-mono's
home page at Google Code.

Am not sure how come I never made the connection between
Matt Warren and
his involvement in C# 3.0 and LINQ (I only made the connection
while
reading Tim Anderson's review of VS 2008).

I have been re-reading his blog in fascination in my spare
time,
but this
caught my attention:

Ever since I joined up with the C# team nearly two years
ago I've been frustrated by my inability to wax poetic about
all the goodness we were working on. I was sworn to
secrecy. Mum was the word. Perhaps if you were paying
attention to the work in C# 2.0 and C-Omega, you may have
guessed what was to come. Looking back, it's easy enough to
recognize it in the design of Generics, Iterators and
Anonymous methods. The existence of Nullables in there as well
should have made it obvious. We were planning ahead for the
big pay off, language integrated query.

You may be amazed that so much planning goes on in the features that
we roll out version to version. Sometimes big ideas and
far-reaching visions take many releases to come to
fruition. You cannot always do them in one release. Sometimes
you have to take a risk and dole them out piece by piece. This
may cause a bit of confusion at first, when no one can truly
understand why a particular feature was included and not
others, or why one design was chosen. Yet once all the pieces
are together you can finally make sense of it all, and then as
if by magic it all just seems right.

At some ECMA meetings in 2004 (the time stamps for some of
my notes on the disk are January of 2004) some of the new
features were being presented at ECMA and it was obvious to
see the benefit for those features (generics, check; anonymous
methods, check; iterators, check; partial classes, check) but
a few of the features made no sense.

Nullable type decorations made no sense to me ("int? a").
I remember feeling that they were pure compiler bloat and that
the use case of databases made no sense. Am not a database
developer, but I felt that the syntactic sugar at the time
really was not bringing much to the plate. During one of the
meetings, I remember putting together a parody for new type
qualifiers (which is the timestamped file I kept) for other
domain-specific features that I felt were just as useless.

Even with early access to the C# 2 specification for so
long, I did not see these components coming together and
fitting perfectly to create LINQ.

We are doing some work to make Windows.Forms and
Moonlight
accessible. The desktop team is hiring people for the
Cambridge office (USA) that want to work on accessibility
technologies, free software, C#, Mono and
the UI
Automation framework.

If you are
interested, drop
me an email with the subject line "AccessibilityJob" and
we will reply in the next couple of weeks with one of those
exercise
interviews that we do.

Although a lot of the work will end up in Mono, this is
part of an effort from the desktop team, so technically you
will be reporting into a different organization than the Mono
team.

Amazon reports that a
new Chomsky
book is on the pipeline. Essential Chomsky. Hope it is as
awesome as some of the collected essays from Gore Vidal.

Am myself a fan of
his Understanding
Power book. Maybe as much as a fan of it, as a fan of
the various Gore Vidal books that they sell on airports, the
pocket book editions (Imperial America, Perpetual War for
Perpetual Peace).

Having missed on games for the past 15 years last year I
finally got myself a Wii. Other than Wii Sports and now
Metroid 3, I have yet to find anything worth playing.

Nat recommended a Nintendo DS, and you guys had
some great
suggestions back in September. So far the only one I
liked was Metroid Hunters (the control is so similar to the
Wii, that its a pleasure to play) and am still making my way
through the Sudoku's on the DS.

I tried Halo3 but with its up/down/left/right-cursor-like
technology to aim at enemies, it feels almost like am playing
with a keyboard in 1988. After using the Wii for
point-and-shoot, anything short of that for point-and-shoot
feels unnatural. Like when the dentist stuffs your mouth with
junk and still tries to have a conversation with you or trying
to use a bendy straw for snorkeling.

So am looking at expanding my Console Empire at home and
purchasing either a PS3 or an
XBox360. Aaron insists that I
should not get the PS3 because Blue Ray this-and-that which I
do not particularly care about.

Aaron also claims that eventually you get used to
up/down/left/right. I guess I will have to live with that, as
the Wii is barely getting any games worth playing. And as a
rule, I do not play anything that glorifies war, but am OK
shooting at strange looking aliens.

So am stuck, and willing to learn to use those unnatural
controls on the PS3 and the XBox if there is something worth
playing.

Dear readers, what should I get, PS3 or XBox? And which
games are worth playing? I do not care about movies on
demand, or whatever other TV features they are trying to sell
me, I already have Tivo HD and Tivo with DVD playback and
recording.

I still hate the classification of anything that describes
itself as enterprise (and I work for a company slogans are
sprinkled with enterprise).

Yesterday someone emailed me:

It was not the point of your blog today but I'd be interested
in hearing about company's usage of Mono in embedded
systems. Because of our affinity for C#/.NET we originally
looked at WinCE for the next generation of one of our product
platforms. It didn't go very well (we were still at WinCE 5 so
I can't say how 6 is). Ironically, using Mono on a Linux
Embedded system seems to give you more .NET / C# then you get
with CF on WinCE.

So I reached out to a friend that has raved about Mono in
the past, and I wanted to get a quotable answer from him (I
asked him if I could quote one of his emails from last year).
He did give me a quote that I can send around to folks, but
his company will not publicly endorse his quote.

Which is exactly the problem that I was describing
yesterday. Anyways, the quote is:

C# and mono is a great way to develop embedded products. If
you separate the heavy lifting from the application logic
properly, the performance impact of C# is not significant and
makes application development much faster and less buggy.

I've been doing embedded development with C# for over 5
years and mono is way better than .NetCF due to superior
performance and binary compatibility with MSFT's desktop .Net.

One thing that is particularly handy is that you can
prototype on a desktop PC and just drop the managed binaries
on the device and they just work - no need to recompile.

So anyways, you are going to have to trust me that I did
not make up that quote myself.

And
today we
delivered a gift (or in Don Box parlance, a "small bouquet
of flowers") for those embedded people that use ARM
processors.

Update: The author of the quote comments:

When you mention embedded development with mono, it might be
worth mentioning that there is some startup cost for the JIT,
depending on the CPU speed and how much managed code there is,
and that the memory footprint with mono will be larger than it
would be without. For most devices this may not be an issue,
but it is something a device developer should keep in mind.
Hopefully the AOT support will mitigate the startup costs.

Rusty has setup a nice page that tracks
the Moonlight
1.0 status with various applications out there. We are
using this as part of our QA and development process.

As it turns out, it was easier to support .NET-based
Silverlight (1.1) applications than the Javascriped-based ones
(1.0) as the .NET-based ones tend to do all the heavy lifting
in managed code. And it was very easy for us to use tools
like corcompare to ensure API completeness.

With 1.0, the story was different, we were debugging things
on a when-we-find-a-problem-we-fix-it approach. JB recently
created a tool
based on the Microsoft specifications that helped us close the
gap quickly. We went from hundreds of missing entry points to
less than a dozen in a week.

We now have cute Firefox installers for 1.0 and 1.1 on
Linux/x86 and Linux/x86-64, once we have the new codec
framework in place we will make them available to the public
for testing. In the meantime, people interested in testing
Moonlight still need to build it themselves. See
our Mono
Olive mailing list for details.

We are looking for volunteers to test the support and post
their findings to [email protected] In particular,
we are hoping that this should further reduce startup time and
memory usage on Maemo devices.

Schley makes a few good points, but its worth pointing out
some things:

2. People assume that Mono is not ready for the enterprise.

One of the reasons for this is because not many enterprise
projects are being built with it (I'll get to that later.)
Instead, Mono is primarily being used to construct desktop
software.

The second reason for this misconception is the Mono
project's inability to stay in step with Microsoft
.NET. Currently, Mono is somewhere between .NET version 1.1
and 2.0 while .NET 3.5 was just released. This is not the Mono
team's fault. Microsoft does not collaborate with them, so
everything the Mono team accomplishes is through their own
blood, sweat and tears. Nevertheless, this version discrepancy
creates the perception that Mono is just a .NET wannabe.

[...]

With the exception of iFolder, Mono is not being used to
develop any truly useful enterprise applications. Great
desktop applications are being created, like Tomboy and
Beagle, but no one has created the next great server
application using Mono.

He is correct that Novell's use of Mono has been mostly
focused on the desktop.

But there are quite a number of applications beyond the
desktop that are being developed with Mono outside Novell. We
have been tracking a
list
of companies using Mono and the list
of programs
and libraries
keeps on growing every day.

A problem that we do have is that of the companies
using Mono have policies of not publicly endorsing third party
products. Also, we typically only find out about who is
using Mono when they have a bug to report, or need some
new feature to be implemented. And in many of those cases
we are not in a position to use them as reference customers.

If you look at the posts, sigs and domains of people
posting to the forums and the mailing lists, you will get a
better idea of what kind of applications people are building,
and who is building them.

A few companies have agreed to allow us to publish success
stories about their use of Mono, some of them are:

Some other serious uses of Mono, but without a full
success-story case
include Fiducial.FR
(their intranet runs on
Mono), Zing (mp3 and Sirius
radio players), Medsphere
(Health Care software),
Quantify Solutions
(financial
tools), MindTouch
(commercial Wiki hosting) and its even used by companies in
the USC 2257 space to build enterprise solutions (for an
interesting definition of enterprise).

At least a few years ago, the Wikipedia search engine was
powered by Mono. I do not know if that is still the case.

The goal of the Mono team at Novell is not only to help our
internal users, but to make sure that external developers can
use Mono without a problem. We fix bugs, improve
performance, improve compatibility and write new libraries
(both Microsoft compatible, or part of Mono's own stack).

Maybe the issue is that we do not have a lot of server-side
applications that are part of a default Linux install. What
we do have are plenty of vertical applications that people are
developing or porting.

Memory Leaks If you have ever used Beagle you know that it can
heinously crash your system. Since it's inception, Mono has
been plagued with a random memory bug. Your system memory will
go from 1% to 1000% in a matter of seconds, without
warning. If the Mono developers want to make Mono more than
just a desktop hobbyists language then they need to fix this
bug once and for all.

As for memory usage problems: there are certainly memory
leaks in Mono, but nothing as bad as a show stopper.
Mono can not reduce memory usage if an application uses a lot
of memory. Sometimes the blame for memory consumption falls
on the application and is usage patterns.

Beagle might have had bad memory usage patterns on its
early days, but a lot of this changed in newer releases.

There is one particular class of memory-hungry
applications: any .NET applications that used generics (the
2.0 profile) extensively was negatively impacted by memory
consumption before Mono 1.2.5. On one hand, we are glad that
application developers switched to 2.0, as they helped us find
the bugs and limitations in Mono, but it also meant that users
had to suffer as we understood all the ramifications of the
2.0 profile and generics.

Python Effect There is a huge movement in the Gnome community
to make Python the standard language for Gnome
development. Mono is a close second, thanks in part to the
great desktop applications being written with it. However, if
Python is officially adopted, there will be a backlash against
Mono, or pressure on developers to adopt Python and port their
once Mono applications to the official language. In order to
prevent this from happening, Mono developers need to
demonstrate Mono’s cross-compatibility.

Python is indeed making great strides as a desktop
development platform and am not sure that we are in the
business of competing with it. If people like writing Python
code, they should just keep writing python code.

Myself, I like the IronPython variation of Python more.
IronPython just happens to be JITed Python and in most tests
it is faster than CPython. For the past year or so, we have
also been in love
with Boo, another .NET
language. Boo has support for strong typing, so for certain
scenarios you will get even better performing code (basically,
when you can determine the type of a variable ahead of time,
instead of having the variable be entierly late bound).

At the Mono Summit, a developer had built a game that was
scripted with Python, said something more or less like this:
"Our game used to be very slow, when we switched to Mono, all
those problems went away" (edited for political correctness).

So each developer will make up his mind as to what is best
for a particular use case.

The Mono team needs to
have Mono installed by default into Linux so that if you write
an application with Mono it can run in Windows AND Linux (and
even OS X).

We agree with that. Applications built with Mono on Linux
already work on Windows and MacOS (including Windows.Forms).

When it comes to Gtk# applications, Our Mono on Windows
ships with Gtk# and
we recently
announced that we will be supporting it as well on MacOS X
and that we will be extending our OSX support.

I find it odd that Red Hat would make those claims, as for more
than a year on all sorts of meetings SUSE Real Time
development status updates come back and forth. Usually they
are high level, but we get to hear a lot about Moiz's team
work at these meetings.

Kevan Barney from Novell
PR posted a
response to the claims that Novell has not contributed
code. And points to
the mailing
list where you can see that Novell engineers have been
contributing code and participating on Real Time Linux with
the rest of the community for a long time.

In general, the focus of the Mono team is on Unix system,
and more specifically for open source versions of Unix (Linux
and BSD) but we still provide provide some support for Win32,
Solaris and OSX even if they are proprietary and OpenSolaris
(even if its licensed for mininal collaboration and cross
pollination with Linux).

In general, our cross platform story has suffered a little
bit when it comes to GUI toolkits: our Windows.Forms
implementation works with X11, but Mac users really want to
run a native version of it, without requiring an X server.

Gtk# suffers from the same problem: it works on X11, OSX
and Windows, but on OSX it requires the X11 driver which is
suboptimal.

In general, I do not like to support proprietary operating
systems, but in the particular case of OSX, there is enough of
a user-base that it made sense to bend backwards for the sole
purpose of increasing the contributor and user bases.

At the Mono Summit we outlined our new strategy for OSX:

Our Windows.Forms now has a native OSX back-end.
Mono 1.2.6 will ship with it, and Mono 1.2.7 will ship
with several upgrades (some already on SVN) that will
make Windows.Forms applications run even better on
OSX.

We will distribute Imendio's
Gtk+
for OSX and Gtk# as part of our runtime. It has
now reached a maturity point that allows applications
like MonoDevelop to run natively (without X11).

We will distribute MonoDevelop for OSX users as a
pre-compiled package, and we will provide support for
it.

MonoDevelop will also be ported to Windows. The
work necessary to port MonoDevelop to OSX is also
going to help the port of MonoDevelop to Windows.
This should be useful for people that are building
Gtk#-centric applications on Windows. For other
uses Visual Studio and SharpDevelop will continue to
be better IDEs to use.

We will support the following, but only as a lower
priority, and work on them will be preempted by other needs in
Mono:

We will support Objc-Sharp for those that need
bridges between Objective-C and Mono. But

We will depend on the community, and provide some
assistance to those that rather
use
the CocoaSharp
bindings to the native Cocoa APIs.

A screenshot of a Windows.Forms app running with the native
driver (click for a full shot):

A screenshot of MonoDevelop, our Gtk# based IDE on MacOS
with Gtk's native OSX driver:

We are shipping MonoDevelop 1.0 at the end of January,
after this, we will start work on the debugger integration
into MonoDevelop (the most requested feature) and we will also
add support for developing Silverlight applications with it.

At the Mono Summit, we got Moonlight running on MacOS X
(including desklets!) which means that our Silverlight
designer (currently called LunarEclipse) will be available on
MonoDevelop on OSX. But we will not support Moonlight on the
browser on Safari or Firefox on OSX as you can run Microsoft's
edition there.

The summit was fantastic. The first two days we
did a bit of internal planning for the project (we had Novell
employees and contributors that day).

Although I had originally wanted to have as much empty
space as possible to do some
more Unconference
style presentations, we probably had too much structure in
place. At least we had some large holes between
presentations for people to talk to each other (except that
not one talk finished on time, which meant that we were always
a few hours later to end the day).

The event was supposed to end every day at 17:45pm, but
most of us barely left the place before 9pm (which was nice of
them, to keep the place open for us until late). Followed by
a late-dinner in Madrid, and a then some socializing in the
hotel lobby or nearby bars turned into four hours of sleep
every night.

Thanks to everyone that made this happen, and for our
Ismael Olea who provided
our logistic support at the event every day and Alejandro
S�nchez that got us this beautiful venue in Madrid.

I hope that all the attendees got to talk to the team
members; I know that many of you did, and I hope that we
fixed your issues, or we came up with a solution for your
issues.