C#, .Net, and Mono

[prev] [thread] [next] [lurker] [Date index for 2006/12/27]

From: jrodman
Subject: C#, .Net, and Mono
Date: 14:02 on 27 Dec 2006
On Wed, Dec 27, 2006 at 11:57:15AM +0200, Yossi Kreinin wrote:
> From the words you've accidentally forgot to delete, I sense that you 
> dislike C#. Is this based on experience or on the fact that it comes from 
> Microsoft? You know, they say the German highways built at the time of 
> Hitler are still decent highways.

I read it as an indictment of fadism and unthinking worship of
"progress" which is really just "change" at the expense of reliability.
Which is a pretty fair target.

But you're right.  Managed environments may pay real dividends over
time, even if Visual .Net shits the bed and forgets its dependency rules
regularly when I use it.


> Aaron J. Grier wrote:
> >why aren't you playing^Wdeveloping in C#?
> 
[...]
> 2. I haven't look into it, but I assume that .NET implementations outside 
> of Windows have a quality below the level where you can hope to get 
> "portable" code (and by "portable", I mean running on Windows & Un*x).

Oh, wow, this is a whole arena of hate.  I can't really do it justice
but I'll provide some tidbits.

You speak of the .Net reimplementations, such as GNU Portable.Net and
Mono.

When I tried Portable.Net, it was FILLED with classes and
implmentations which could not ever have worked.  Things like an object
with an update function that overwrites your data instead of the
object's data.  Good times.  It was also slow enough to fall into the
Python category, which is okay for some tasks, but Python is way more
productive and portable, so it didn't seem worthwhile to use
Portable.Net at the time.

Mono had a working CIL compiler and CIL runtime with JIT that performed
pretty well, so it worked for our purposes.  Well, sort of.

One problem with .Net is it sort of makes noises about providing a
portable api, but it mainly does this by insisting on (stupid) win32
semantics.  For example, the win32 file locking behavior we went round
and round about is now exported to Unix, lest .Net programs fall over
when running on non-windows.  

Another example of this would be the DirWatcher class, which provides an
abstraction over something like inotify.  You tell DirWatcher that you
want to know about changes to a certain set of files, and then it tells
you when changes have occurred via a callback, freeing you from
implementing obnoxious polling, and probably doing obnoxious polling
itself in many cases.  But maybe doing something smarter sometimes.
This is really nice functionality for a lot of purposes.

The problem with DirWatcher is that you specify what things you are
interested in with a glob expression.  The ECMA spec says that the
default expression is "*.*".  The fun part is that the ECMA spec does
not tell you what "*.*" means.  You could presume you should use native
globbing behavior, which would make your applications nonportable.
"*.*" matches anything on windows, and only files with a dot on Unix. (I
have no idea what Mac developers think about such expressions.)  You
can simply refuse to implement the spec and default to "*" on Unix,
assuming the intended default is to notice all changes in the directory,
even though this is not what the spec states.  But then what do you do
when a program passes in "*.*" explicitly?  Is it possible to do
anything sane here?   Please note of course that the actual behavior of
windows globbing (in its full details) is not specified anywhere, varies
across windows versions, and is defined by its behavior.


There are other issues with .Net.  It's a leaky win32 abstraction.  To
Microsoft's credit, they are removing some of the leaks as they
reimplement the interfaces repeatedly, CADT style.  So maybe this will
become less of a problem over time.


But Mono itself is a true joy.

Because Mono has to implement all these "system level" semantics that
don't exist on unix, it has to create a sort of pseudo-system-wide layer
itself.  This means that all your Mono processes have to be able to talk
to each other.

The way it does this is the first Mono prcess you launch is not really
your process.  It is a "handler daemon", which in turn runs your
process.  The life of this "handler" wil be the time that you are still
running any Mono tasks.  This makes launching and managing pids in
normal unix ways a real fun task for Mono tools, but that is easily
worked around.

The fun part about the handler daemon is that it communicates to its
spawn through a socket and some other mumble in a fixed path from $HOME
($HOME/.wapi/mumble if I remember correctly).  Thus if you want to run
Mono tasks under accounts that do not have their own private $HOME dir,
they tend to crash and burn.

But that's not all, because Mono isn't fully baked, the handler daemon
sometimes gets wedged.  In this case, every Mono task communicating with
the daemon will also wedge.  Recovery is accomplished by manually
killing all the processes.  This is especially graceful because Mono
cannot map signals into .Net in a portable way.  I don't remember
whether it doesn't support them all, or only in Mono specific way,
which was unfortunately not allowed in the hateful time that I used
Mono.

But is this wedging behavior common?  I mean, does it really happen so
frequently?  Well, the communications api breaks is incompatable across
versions of Mono.  This means that you can never run two versions of
Mono in the same account at the same time.  Like say when you are in
the process of upgrading to resolve a bug.  If you do something foolish
- like try to build the new version of Mono, which requires launch Mono
for part of the build process - all Mono instances, old and new will
lock up.  I think there was even some extra joy of some sort that the
build, halting abruptly in the middle required some manual cleanup
after killing off all the Mono processes.

But the _best_ part was that after you managed to wedge all your Mono
processes, and had to send them all a kill -TERM (or was it -KILL?),
newly launched Mono processes (like say from cron), would also wedge.
You had to ensure all Mono processes were exited, and then rm -r that
$HOME/.wapi, before any Mono programs would ever work again.

This, my friends is the future of Enterprise Class development.


[irrelevant to the rest]

> On the other hand, someone can get so good at grepping around the
> filesystem that definition lookup doesn't look like a win. Some people
> prefer to create digital images by manually setting one pixel at a
> time, and if they are good at it, that's fine.

The definition lookup facilities of emacs, vi, whatever other
time-honored tool, may be clumsy in some ways, but they certainly have
existed longer than Visual Studio.

These days they have all the _capabilities_ of something like
intellisense, even if the usability of them is open for debate.

-josh
There's stuff above here

Generated at 03:02 on 01 Jan 2007 by mariachi 0.52