> A lot of people attacking Mono it seems. It's just silly.
I don't think it was attacking, I think it was being realistic.
> Some argue here that you really shouldn't use mono because of
> the massive investments some are spending on Java in the Linux realm.
> However, throwing money at something doesn't always make it
> better. For all the same reasons people are choosing .NET on
> Windows over Java, people are choosing Mono on Linux,
> FreeBSD, MacOSX, HPUX, OpenBSD, NetBSD, (and even Windows
> where people want a native 64 bit version of
> 1.1) over Java. Oh, and Mono also works as a pseudo JVM via
> IKVM extensions (using a process of on-the-fly Java byte code
> to CIL conversion).
So, if I compare Mono with Java, Mono will turn out to be better?
Because that's what I read in your paragraph.
> Some argue about COM and Enterprise Services not being
> supported on Mono is a reason not to use Mono. Well one of
> the largest features and selling points of .NET is the
> migration away from COM (oh by the way, we are starting to
> support COM on our WIN32 builds). I have yet to find a
> company or product that is really even using Enterprise Services.
Just because you don't know them, doesn't mean the # of people using
enterprise services is small. Anyone who needs a
distributed transaction needs enterprise services. System.Transactions is for
now SqlServer 2005 only, Oracle for example won't
support it till they've changed 10g.
> Back to what Phillip Holmes said about write once and run anywhere.
> That's the point of Mono and it is very much realized. A
the thing is: is Mono 'another platform' or is Mono .NET which runs on
Linux (and other platforms)? This is significant. If
it's the latter, you could just develop on .NET, and run the binary on Mono. If
it's the former, it will take time, effort and thus
money to make a project's software run on Mono and _KEEP_ it running on Mono.
The porting alone will introduce bugs in the software
which have to be debugged. How? Is the development environment of Mono on par
with tools available for .NET? I'm sure there's a
debugger, but is it on the level of gdb or more usable? Will the team be able
to utilize the tools available to debug the code
ported to mono that it will keep on running on Mono?
That's the point this discussion is about. If money and time aren't an
issue for a project, then Mono is likely not an
issue. THough if money and time are an issue, porting to mono _can_ hurt your
project IF it requires porting. So if it can run
binaries compiled for .NET without a problem, in _ALL_ situations, it's a big
difference compared to the situation where code has to
be ported to the platform.
And don't think lightly about this. Every method of every class can
behave differently. I admit it was about 1.5 years ago I
ran my last mono program, but back then SqlDataReader.GetValue() returned null
instead of DBNull.Value if the field in the row was
NULL in the db. Small detail, but it's a difference between Mono and .NET,
porting code over will in such a situation be a problem,
as you've to test through and through again every detail of your application on
Mono because it's not equal to .NET in _that_
situation.
Perhaps Mono has become '.net on linux' instead of 'another platform',
or will be soon. But I find it necessary to point out
the difference between the two, as the difference is significant for project
budgets, resources and time available.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
