Why Mono Is Desirable For Linux

[bornslippy]

You can't assume SSE2 on your executing platform.

ROFL, whatever... If your application isn't performance sensitive(and most aren't), then Java vs. C++ performance is a moot point.

If your application is performance sensitive, then you can begin to assume all kinds of things, but for heavy floating point applications, I ALWAYS optimize all the way up to SSE3 for my pre-compiled binaries, I've found 2x speedups in real world use, and about 2x speedup from various other CFLAGS like floop-optimize, etc... People without SSE3 capable machines have no business running such applications anyways, I'd rather leave them with nothing at all then an awful experience from my "slow" application on their slow PC, rather than screw my 95% of users who came to the party with a proper computer that's less than 6 years old.

Then there's the alternative strategy of compiling multiple binaries, then having /usr/bin/your_application_name select one based on querying processor capability on the current machine, which pretty much destroys your argument. However, 99.999% of applications don't need such elaborate measures because they'll never run a single modern CPU core at 100% ever, so it's still a straw-man argument.

[jrch2k8]

You can't assume SSE2 on your executing platform. Take a Linux distribution as an example, you need to build things for the lowest common denominator. Debian's i386 version requires a mandatory i586-class processor as a minimum, for example (i.e. an original Pentium 90MHz is supported). A JITter is great for supporting wide classes of system, since it can enable run-time optimizations that GCC flags can't

your affirmation is java/.net can be as fast or faster than c++ and that will never be true no matter the VM/Jit you use cuz you are bound to compare code equally or optimally optimized in both languages and using the best tools for each language[that includes compiler] and in that scenario C/C++ smoke anything else[fortran/pascal can be the excepcion].

now if you write crappy code Jit languages will make your life somehow easier than write crappy code on C++ and crappy code can be faster in a VM due to certain optimization passes that a compiler won't do unless instructed <-- here you are right.

about SSEX/AVX there are many solutions to that hence require more brain time but is perfectly doable

[frantaylor]

crappy enterprise applications.

In the enterprise you WANT a forgiving language that allows newbie programmers to be able to contribute.

People who write enterprise apps are not thinking about cache hits and memory allocation. Their heads are filled with the arcane and oddball requirements of their application and they don't have the time or the inclination to fret about low-level issues.

Who cares if the payroll batch job takes 10 minutes instead of 2. Performance is irrelevant. Correctness in finite development time, using relatively inexpensive labor, is the primary requirement.

Right tool for the job!

[peperoni]

I think that there exist more IDEs in Linux that allows junior developers to write programs in C/C++ aside Monodevelop without cutting their throats. For example Codeblocks have a very good GUI editor, and a lot of professional features like code completion. Codeblocks is fast and allows to develop in machines with low resources like the Raspberry Pi or the Beagleboard. Besides, it has a lot of code examples to start with (open gl, wxWidgets, console application...).
At last when I develop programs for Linux I try not to use fast food languages and try to stay besides C/C++, because I feel very comfortable, there exist a lot of libraries and programs programmed in them, and they allow me to take the most of the machines I develop for.

[bornslippy]

In the enterprise you WANT a forgiving language that allows newbie programmers to be able to contribute.

People who write enterprise apps are not thinking about cache hits and memory allocation. Their heads are filled with the arcane and oddball requirements of their application and they don't have the time or the inclination to fret about low-level issues.

Who cares if the payroll batch job takes 10 minutes instead of 2. Performance is irrelevant. Correctness in finite development time, using relatively inexpensive labor, is the primary requirement.

Right tool for the job!

Unfortunately for .NET and Java, the right tool for those jobs is the even-easier-to-use interpreted languages like PHP, Python and Perl. Since 99.99% of enterprise applications are browser-based applications running on a company's local intranet that simply read/write to a database and spit out pretty web pages to a browser, Java and .NET are complete overkill. The added complexity of running a Java based website(Hudson or Jenkins build servers, JVMs, etc...) is rarely ever needed, and the alleged performance gains of running a "compiled" binary for your web application are MIA in real life. Then there's ASP.NET, which is a complete joke.

[geearf]

"OVERNIGHT"

Somewhere above I read that C# was introduced in 2002!

Since when is 10 years "overnight" It did not take Microsoft 10 years to write Word or Excel.

And I thought these new development environments were supposed to make development EASIER and FASTER. You say it takes LONGER now???

I see.
Well I do partially agree with you on that.
It seems the issue is that the products have to move forward, not even a year can be taken for re-platforming... unless there is a MAJOR (^MAJOR) benefit.
It may be possible that some old C++ code here and there would be rewritten... unlikely all of it would be for a while...
Plus the truth is, as long as something "works" and that re-platforming is (more) painful, it is not going to happen I guess...


(I take back my previous negative comment, sorry)

[russofris]

Unfortunately for .NET and Java, the right tool for those jobs is the even-easier-to-use interpreted languages like PHP, Python and Perl.....
...[some BS about "enterprise browser applications and their backend implications"

Java and .NET (and other IR/JIT technologies) are major players in enterprise computing. In addition to ApacheHTTPD->Tomcat->JBOSS->JDBC or IIS->ASP.NET->.NET->ODBC stacks, Java/.NET are often used for middleware behind the technologies you reference. I would counter that Amazon is a good example of an enterprise load that surpassed Perl's capabilities in both performance and software development terms. Perhaps we have an old-time Amazon SE registered that can comment about 2003->2006.

F

[bornslippy]

Java and .NET (and other IR/JIT technologies) are major players in enterprise computing. In addition to ApacheHTTPD->Tomcat->JBOSS->JDBC or IIS->ASP.NET->.NET->ODBC stacks, Java/.NET are often used for middleware behind the technologies you reference. I would counter that Amazon is a good example of an enterprise load that surpassed Perl's capabilities in both performance and software development terms. Perhaps we have an old-time Amazon SE registered that can comment about 2003->2006.

F

Was there a point to all of that?

So, according to you, Amazon supposedly does/did run on Java, so you compare it to Perl? Why not compare it to Python, which is used extensively at Facebook and Google, the #1 and #2 websites for traffic? If Java was so great, wouldn't they use it too? Let me guess, you're a Java developer, therefore you must defend Java's honor?

Of course, that was obviously not the kind of "enterpise application" I was referring to, I was referring to the kind of development-for-dummies internal applications that large companies develop in-house(or outsource to India) to be used in-house only...

[randomizer]

There are a large number of people here who take themselves far too seriously. Please stop looking at your programming language and development environment as a religion.

[n3wu53r]

I can't speak much about the technical or legal details of Mono or Java. I'm still learning programming and almost everything I do is in C/C++. But from a purely end user prospective this is what I have observed amongst desktop apps.

- Java applications using SWT or Swing look awful.
- Mono applications don't because they are using gtk# bindings. (never seen winforms actually in use on linux).
- Java applications have atrocious RAM use
- Mono apps are still higher then I feel they should be, but not like Java.
- I've had crashes with both but I think a bit more with Mono.

Maybe Java and C# just allow for sloppy programming which could be the causes of many of these issues, but I'm not impressed with either.

From the whole legal thing, I think it's a bad idea to start a C# app with the intention of using Mono on non-windows platforms. I think it's fine if you had an old C# app that you need to port over and don't want to rewrite, but why the hell write a new program from scratch using mono from the start?