Both use lots of memory though. Tomboy.exe, which is a note taking app, currently has a VM size of 386meg, 33.8 of which is resident. From looking at /proc/../maps for this process, it looks like most of it is taken up with Mono .dll files, which, while it's good these are mmap'ed and sharable libraries, ain't much being shared since this is like the only popular Mono app. It looks like every Mono .dll is being loaded for this program.
But this reminds that I wanted to remove Tomboy from my panel since I don't use it and it has some serious reliability and UI issues.
Just consider it a preloader for your other Mono apps. Once you go to launch Banshee, all those dll's are already mapped and ready to go! And hey, it happens to take notes, too!
It's more common in a server environment. I'd expect to see more Java installs as the popularity of JVM-based language implementations rise, such as JRuby, Clojure, and Scala. I am, for instance, working on putting together a JRuby stack for my company's web applications.
My list is jEdit (used on Linux), SmartCVS/SmartSVN (Linux/Win/OS X still get used sometimes, but much less - moved away to git/bzr), Azureus (on OS X, least used of them all thanks to Transmission and now uTorrent).
Interactive response is not measured with a number crunching benchmark. It's measured by UI latency. Eclipse itself (assuming SWT is considered better than Swing) is still remarkably slow when compared to MonoDevelop.
Mono certainly aims for better integration into the Linux userspace, at the cost of portability.
The emphasis of Java on portability / platform agnosticity is one of it's strengths and one of its weaknesses. It's part of the platform's identity. Comparing the two platforms about linux desktop development is almost nonsensical, since for mono, linux desktop apps is the selling point (GTK# is designed as the main GUI framework for mono, and it gives a native feel on linux), whereas Java has a much broader audience at the moment.
This makes sense. From the very start, Mono was intended to be used for creating desktop applications for GNOME. Java has been lousy for the desktop starting with the decision to use a least common denominator window kit. AWT specifically excluded widgets that were not natively available on every platform Java ran on. The idea was that they would blend in better this way. The result was a sub par window kit that was only as good as what was available on the worst platform. Sure, we got SWT later, but that still has problems of its own.
The fact that Java is not terribly useful for creating desktop applications is irrelevant. Its strength in server side applications has long been established. Not to mention, Java has kind of become a de facto standard for a lot of corporate development and those applications are very rarely distributed. Public distribution of applications written in a particular language says almost nothing about the level of usage. There are plenty of other good languages that are not commonly used for desktop applications so I don't understand why this is particularly newsworthy. It's not every day that you see desktop applications being developed in Python or Ruby either.
How can you trust an article with glaring factual inaccuracies underlying the primary argument?
"Eclipse 3.1 lacks features that MonoDevelop has, including code completion, integrated debugging, refactoring, and unit testing capabilities, Hargett claimed."
Are you kidding me?
And then the great "apps" they site for Mono are Gnome Do & Tomboy notes. Sorry but we're working on visual programming language plugins on top of Eclipse at my company, and the two Mono apps they site are to-do lists?
I'm all for Mono, I'm all for a discussion on how Sun screwed the Linux community over, but this article is not worth reading or talking about. Shoddy reporting all around.
"It's also worth noting that many of the high-profile Mono applications are written and maintained by Novell. That's a pretty classic platform strategy—try to get your platform broader distribution (in this case, integrated into the Gnome desktop) by creating compelling applications that require it."
The "Creation of Compelling Applications" isn't a strategy, it's the only reason that platforms exist.
Just tell me when it outpaces c++. How many mono apps are there? How many c++ apps? Mono has a really long way to go before it can seriously challenge C++/KDE. I hope not to be misunderstood, moving away from c++ is somewhat a good idea, but its much too early for statements like this, because how many java apps are there to be outpacet?.
This just adds weight to what I've been saying all along: C# = The Java Killer. Also, there's more java on linux than you think. Hell, Android is a whole platform for java on Linux, which is the dumbest possible thing to do, which is why its failing miserably :-)
I'd never heard of MonoDevelop, and it seems to me this article was really scrounging to create a sense of its "primacy" that isn't real.
Neither sfbay-craigslist, Indeed, or SimplyHired come back with any job listings that mention 'MonoDevelop'. Meanwhile, even combining the three terms [linux eclipse java] gets multiple hits at Craigslist and over a thousand each at Indeed/SimplyHired.
There's a fair chance that Eclipse itself is the most popular Java desktop app on Linux. (Developers aren't blocked by outdated Debian packages nearly as much as the article implies, and the article's claims about what was missing in Eclipse 3.1 are false.)
Azureus and LimeWire have also been widely-used Java desktop apps, on Linux and elsewhere.
There are lots of people using Linux to develop Java, but that doesn't mean they're using Java to develop desktop apps for Linux. Mostly they, like you, are using it to develop server-side web apps, I think.
I think the article is correct that most people aren't choosing Java for new projects they start. I assert without evidence that the Java job listings you see are primarily for existing projects. I wouldn't be surprised if you chose Java for a new project, but it seems like most people prefer Python or Ruby or C# or, for some things, C.
There's not much standalone desktop Java anywhere; it's clunky for that purpose. But the article is claiming some sort of Mono/MonoDevelop ascendancy for Linux desktop apps, and that's not in evidence.
For example, I'd estimate the usership of Eclipse and LimeWire on Linux as larger than any two of the Mono apps mentioned in the article or this thread.
'linux eclipse java' would net you all the server-side Java roles. This article is about desktop app development.
If the most popular Java desktop app on Linux is an app used exclusively by software developers, then Java indeed has issues creating end-user apps, as there are far more Linux end-users than there are developers.
Interestingly, on both Mac OS X and Ubuntu, Eclipse is the only app I have to wait for a context menu to pop up when I right click a project. It is also the only Java app, as Android (what I'm developing for) has different UI libraries.
Writing non-trivial / multi-threaded desktop software with Python is a debugging nightmare.
I've been a volunteer Banshee dev (~20 KLOC) for about 4 years. With limited time to contribute I wouldn't be nearly as productive if I had used C or Python. Without Mono lowering the (time) barrier for entry I probably wouldn't be a long-term free software developer.
Personally, I'm sad to see JavaScript coming to the forefront with GNOME 3.0.
Writing multi-threaded software in any language, that uses shared state and locking primitives is debugging nightmare. The list of those languages includes not only Python, but Java and C# too.
My experience is limited to one application and I used my own hand-crafted system based on select for this rather than twisted (which I didn't grok until I'd written my own scheduling model). However, the experience was good (and it was a joy to debug - very straightforward) so I'll continue here.
If you're writing python apps you're better off using twisted than the threading system (which in my limited experience is indeed horrid).
Twisted is pitched as being a networking layer, but I find it better to think about it as a purpose built scheduler which happens to have poweful networking modules. To explain what I mean by scheduler: - you have a cycle of standard functions for the application which might handle input, look at the network for traffic, handle output. Sometimes in the course of execution more functions will be needed and you stick them into the cycle. So you have an extra item in the rotation that handles custom tasks. Once you've got a scheduler model like this you can tweak it to make your application more responsive if it needs it.
You can use pyinstaller to produce a packaged binary that can be easily transported between platforms without requiring users to install a stack of python libraries. If you use wxpython as your GUI the whole thing can be multiplatform.
The problem is that I couldn't learn it until I knew what it did, and it was only when I sat down after writing that app and writing out a plan for a generic scheduler library based on what I'd learnt that it dawned on me - "ooohhh that's what twisted does!" We've been best friends ever since.
Leaving aside differences in their user interface design, what's your opinion of Banshee's codebase, performance and stability, versus Exaile (which is written in Python)? I've used neither, but I'm interested in the comparison as they both seem to be applications of similar complexity.
But this reminds that I wanted to remove Tomboy from my panel since I don't use it and it has some serious reliability and UI issues.