[Mono-docs-list] Selling Mono

Adrien Dessemond adrien.dessemond at softhome.net
Wed May 23 08:43:56 EDT 2007


On Wed, 2007-23-05 at 07:15 -0400, Jonathan Pryor wrote:
> On Mon, 2007-05-21 at 22:21 -0400, Vladimir Giszpenc wrote:
> > Numbers sell.  All the benchmarks and performance comparisons are
> > several years old.  Today, Mono uses generics with value types, the
> > compiler and garbage collector have improved.  Someone should be able
> > to come up with a test that puts mono in a good light.  Java may still
> > win so Sun might even accept a challenge.  Testing the Microsoft stuff
> > is not so important.  Someone should sell Mono with numbers.  It would
> > help developers sell their decision to use it to people that don't
> > care about indexers and properties.
> 
> http://shootout.alioth.debian.org
> 
> What I always find to be interesting is that while Mono is frequently a
> little slower than the various Java flavors, it usually requires less
> memory, rather useful for embedded environments...

Really interesting. Do not forget that Java exists since 1995 and Sun
put large efforts on it. Mono is younger and the results it achieves is
amazing, although the way is still long. 

Personally speaking, "concurrency" is may justifiable from a marketing
point of view but technically speaking it is just a choice that depend
on many constraints. In the "UNIX" world, C/C++ and scripts are the
master (may I am a bit old-fashioned ;-)) but alternatives exists and
Mono/Java are one of them. Some projects uses Java for a variety of
reasons, some others uses .Net for others various reasons. Both
platforms will exists and cohabit in forthcoming years. "Cobol is dead
and will die" is in the same kind of debate.

I am using Mono in a personal project for two reasons : firstly he final
product have to be runnable on both Windows and Linux (GTK/Glade
bindings and libs exits on both platforms), second having a robust C/C++
implementation will requires more efforts and will make me focus on the
code rather than putting them in the application internals design. Third
compiling C/C++ applications"in" a clean manner will requires me to
learn how to use stuff like autotools/cmake/etc and this puts a heavy
weight on my shoulders. I could use Java with Swing/SWT, but I am used
to work on the .Net platform, so I took Mono... personnal choice. 

What can I see in forthcoming years : Microsoft achieved a great job but
Windows reached the top or is near the top of the hill. Next versions
will be more like "service packs" and justifying (increasing) migrations
costs will be more and more difficult (discontinuing support is may a
solution but it will not works forever). This is where Linux comes into
the scene : although functional, many major projects like Mono or Samba
will reach another major milestone soon making them being taken into
account more and more seriously by decision-makers since they will offer
complete replacement solutions (glad to see open-source businesses here
in eastern Quebec and how some of them did a great job with
governmental/educational agencies). So it will not be a surprise to see
a Windows/IIS/.NET/[SGBDR here] servers migrating to a Linux (or
*BSD)/Apache/Mono/Samba/[your SGBDR here] ones. 

This is why having a robust and complete documentation for Mono is so
important because it one of the very thing people want to see after Mono
demos. Having a clear documentation is a key point and is as important
has having a complete .Net framework implementation. And this
documentation effort have to be dynamic. I am conscious this requires a
great effort but it really worth it. 


> > Maybe ask an independent third party, or ask someone who has published
> > numbers to redo their tests.  You might suggest they use a 64 bit
> > architecture (I have no idea if this is faster).

I run applications both in a 32 bit world and 64 bits one. No or little
differences in practice ("number crunching" application were even a bit
slower in 64 bits, algorithms/code generation issues ?).


Adrien



More information about the Mono-docs-list mailing list