I've been on vacation and just got back and heard about this whole Richard Stallman spouting nonsense about Miguel being a traitor thing and saw that OSNews had an article criticizing Stallman for such ridiculous statements, so figured I'd skim the comments. Unsurprisingly someone attacked Miguel and Mono for "always chasing tail lights" which is a common logical fallacy that the anti-Mono folks love to argue, but in response there was, what I thought, a pretty good post by elanthis that rings fairly accurately as far as I remember events happening back in 2001 while I was at Ximian so figured I would quote it in order to share.
This "Mono is just chasing tail lights" crap is getting silly.
If you take Mono to mean "a project whose sole goal is to enable running Windows .NET apps on Linux" then yes, Mono will always be behind.
If you take Mono for what it actually is meant to be and what it is actually freaking used for, which is "a project that provides a clean, modern language on which to more efficiently develop and deliver Linux applications" then you realize that Mono isn't chasing anything, it's actually 20 steps _ahead_ of anything else on the Linux front.
If Microsoft came along and said, "we're going to assert some mythical patents and Mono can't be compatible with the ECMA CLR or class library anymore," Linux and Mono would not be devastated in the least by it. Mono would drop the offending bits and it would _still_ be a clean, modern language with a helluva-efficient runtime library providing a ton of brand-new non-Microsoft-derived Linux-focused APIs and libraries (from POSIX to dbus to GTK to OpenGL and so on) that real applications like Tomboy or Banshee or iFolder or MonoDevelop or Unity3D or SunUO or Landell and countless others can continue to be built on top of, taking full advantage of the features of C# (or even a "very similar to C#" language, if some change were forced on Mono by MS), the high quality Mono runtime implementation, and the quality APIs and tools developed by the Mono community.
There's no difference in theory behind a project like Mono and a project like Python, other than that Mono leisurely follows a language specification for the sake of being compatible __as a nice side benefit__ while Python just makes shit up as it goes. Oh, and Mono is way faster, has significantly better documentation, has better tools, and is already used in large-scale commercial apps (that have NO dependency on being Microsoft .NET compatible) despite having been around for a far shorter amount of time.
Honestly look around and see how many people try to use or even _care_ about using Mono as a way to run apps developed for Microsoft .NET. You just don't see it. Mainsoft makes a business out of making it easy to get ASP.NET apps running on Linux servers and that's about the end of it. All of the really cool users of Mono are people that are using it either because it provides a top-notch embeddable VM that blows away every other FOSS scripting engine (e.g., Unity3D) or because it provides some of the best APIs around for creating brand-new Linux-specific applications (e.g. Beagle).
The only people who are even remotely hung up on chasing Microsoft's taillights are the people who don't understand what the purpose of Mono is and use their misconception as a strawman argument against the Mono project.
Mono was conceived by the Ximian folks because of their experience with Evolution. They were writing big Linux desktop apps. Writing them in C sucked. Writing them in C++ sucked slightly less. Writing them in Python sucked far less in some ways and far more in other ways. Writing them in any FOSS-friendly language available was a nightmare. They saw C#. They saw it was like Java, except it fixed many of the things that sucked about Java. They thought, "it would be sweet if we had a language like that to develop in." They thought, "we could write a language like that to develop in." They thought, "we could write a totally new language, but then we have to solve a bunch of problems that have already been solved over and over and over" and they knew that good engineers don't waste time resolving old problems. They thought, "if we make a C# compiler and runtime for Linux, not only do we get what we want, but what the heck maybe it'll help bring more ex-Windows developers over to the Linux side and make the world a better place." And, instead of sitting around bitching about all the hard work other people are doing, they went ahead and made the project. Their lives got easier, the lives of quite a few Linux developers got easier, the lives of even a number of Windows developers got easier, and the regular users started seeing some cool software that none of the Linux developers were making pre-Mono because it was such a time-consuming pain in the ass to do it before, and Windows users even started seeing more cool software because now there was this awesome tool for embedding high-performance reliable easy-to-write scripts into larger applications which made the applications more awesome.
Everyone has won because of Mono, and because Miguel and the many other awesome contributors to Mono have done something FOSS never did before. The only thing the FOSS world has that even comes close to Mono is Java, and that was only just recently Open Sourced, and Sun's Java is actually already way behind Mono despite being far older.
So, seriously, quit with the taillight chasing crap. The Microsoft specification is largely irrelevant to just about all users of Mono, it's not even a priority for the Mono developers, and Mono has far surpassed anything else the FOSS community has in the same field.
C/C++ are a pain in the ass to work with and are light years behind modern languages in ease of use and features, and modern VM technology is already more or less on par with C/C++, and upcoming VM technology is quite likely to exceed the performance of C/C++. Python, Ruby, Perl, and so on are all great languages for some tasks but are total whores to work in for a great deal of other tasks, and they'll never be able to match Mono in speed (simple fact -- even if you implement the same VM technology in something like Parrot as you have in Mono, dynamic typing will always be slower; even if you use the same tracing optimizing JIT to compiler both C# and Python to machine code, the C# result will need far less type guards than the Python result would... which you can even prove by just using IronPython on Mono).
The point of Mono is NOT CLR compatibility. It's not even C# the language. The point of Mono is having a runtime and multiple languages that make developing real-world applications easy and making those applications more reliable, which frees up more developer time to work on actual features and performance rather than working on endless layers of complicated framework code or debugging stupid bugs that only exist because of poor language design.
As always, you have the typical know-it-alls who attacked the response saying that C# doesn't have many advantages over C++/Qt, but as usual, they neglect to consider the fact that not everyone wants to program using C++ or Qt.
As one of the developers involved in the development of Evolution, neither C++ nor Qt were tools that would have helped to solve our problems. First off, Evolution was a GNOME program (thus making Qt useless) and C++ was plagued with problems in those days. I'm also not sure that the C++ bindings for Gtk+ were even mature enough to use at the time. Even had these not been problems, none of us wanted to use C++ anyway.
Even today, with the surviving members of the original Evolution team now working on Moonlight (Chris Toshok, Larry Ewing and myself) which is partially written in C++, we have stuck with a very minimal subset and have gotten frustrated with a number of idiosyncrasies in C++ that were not a problem in C.
As a contributor to the Mono project (along with MonoDevelop and Moonlight), I feel that the Mono detractors are woefully uninformed and seem unwilling to educate themselves, but I guess that's their loss. The Mono Project will continue whether they call us traitors or not, whether they approve of the project or not, and whether they go on making fools of themselves across the internet or not.
We're not interested in childish popularity contests, we're interested in making great cross-platform development tools and making the Linux Desktop more inviting to a wider audience of both users and developers.
And we are succeeding.
63 comments:
Keep it up. ^.^
Perhaps I'm doing it wrong, but C# seems such a tedious language to use.
Probably due to beta aspects, but I could not get any Linux developed Windows projects to actually run on Windows.
I kept getting that 'developing on Microsoft stuff' feeling - were the system is so complex and hidden, and the documentation is bad or confusing, that you spend hours/days searching for code snippets to copy and butcher, so your application doesn't throw some illogical and meaningless exception (it might tell you from the library's point of view, that some assertion is not met, but doesn't tell you what you have or have not done wrong).
Great article
Well said... to the both of you!
For people who aren't interested in "childish popularity contests", you guys try awfully hard and only pretend to be succeeding. Well, actually, you are succeeding among Microsoft folk but no one else.
You say "what if people don't want to code in c++/Qt" as if there was some huge majority of *nix folk like that which is only you attempt at self justification and ignoring the fact that no one on *nix had any interest in Mono and it's only an attempt to force this upon us by Microsofties cause Microsoft tells you what to think rather than thinking for yourselves.
Mono (and every other JIT/interpreted language) should *NEVER* be used to develop desktop applications. Simply because Mono is slow and uses more RAM than compiled languages. The only ones who would ever need to do that are money hungry corporations who want to cut costs at the expense of quality. I consider any desktop application not compiled to machine code to be de facto a poor application and I will never install it.
I actually have yet to see a "killer Mono app" created with all of this so-called "ease of coding".
Just tried a windows app someone made with linux compatibility in mind. It looked crap, text was invisible unless selected, and barely obeyed my theme.
Mono is just so dissapointing for me even as a user.
Jeffrey,
Thanks for the post! I have a technical question here:
One of the reasons I have always avoided Java for general purpose development was its lack of shared libraries, i.e. two Java processes couldn't share any code between them.
Needless to say that's a huge problem for general purpose (i.e. not server-hosted) software. Without shared libraries RAM consumption of a typical desktop would go through the roof, just sort by that "Shared Memory" column in Gnome's System Monitor or in top.
AFAIK Microsoft shares .NET runtime libs between processes (via ngen) alleviating the infamous JVM startup delay that makes Java so worthless outside of datacenters.
How's Mono in this regard?
Thanks!
I've been on the semi anti-mono side because I thought the speed sucked like Java and that's all. If it's faster than Python then I'll go ahead and check it out since python is my main language. Now the main question is, is it easy and fun?
Eugueny: Mono supports data sharing between applications as well. We take advantage of this with Moonlight if there are multiple Silverlight instances in a website or loaded in Firefox in different tabs as well.
Jeffrey,
I asked about sharing code between processes, not data.
Can I create a dynamic library (.so file or dynlib on OSX) which would be used by several different executables with only *one instance* of it being loaded in RAM?
Needless to say, the library code needs to be aware of the fact that it is being run inside of multiple applications simultaneously.
Thanks and sorry for confusion.
Maebara Keiichi: C#/Mono is faster than CPython for most tasks (not sure about *all* tasks, but I think it's pretty safe to say "most").
As with Python, C#/Mono allow programmers to invoke natively compiled code as well, so if some section of code is performance critical and can't be done in C# with reasonable performance, you can easily push it into a C library or something.
Luckily C# allows unchecked code (meaning the JIT doesn't have to waste time on sanity checks) and allows the use of pointers which means that you can very nearly reach the performance of C/C++ for a lot of common data manipulation. Then you have things like Mono.SIMD to help take advantage of hardware acceleration for common multimedia/3D math routines.
No doubt we'll also add support for taking advantage of the GPU as well.
That's one area where the Mono JIT is actually ahead of tools like GCC when compiling languages like C and/or C++ which force you to drop down into assembly code if you want to take advantage of those sorts of things.
Eugeney: Yes, it can share code as well - it works the same as lib.so sharing under Linux.
Robert: I dunno how to argue with your "feeling". I find many FLOSS projects to be severely lacking in documentation far more so than Microsoft's developer tools and libraries. MSDN is far more thorough than what you'll find for most FLOSS developer tools/libraries.
The GNU libraries are decent as are a good portion of the GNOME stack, but there's plenty of core libraries that are undocumented at all.
The difference, I find, is that MSDN is often superior to anything we in the FLOSS world have with their documentation and sample code snippets.
I'd love to see docs improve in FLOSS, which is why I have spent countless hours helping to improve various documentation for various libraries and why I spend almost as much time writing docs for GMime as I do writing code.
I also don't find most of the .NET APIs to be complex at all (a few are over engineered / complex, but I can barely point to any FLOSS libraries that aren't just as if not more complex).
Take for example audio on Linux. That is really complicated no matter what level of abstraction you are trying to work with, whether it be ALSA or PulseAudio - especially when you consider the fact that the PA author feels that it is each individual programmer's responsibility to track audio device plugged/unplugged state. Good grief!
thank you i now understand far more about mono, and i can understand your exasperation.
Thank you for making my life better
drhoward: This may be news to you, but the "Microsoft folk" are 90+% of the market. A small slice of that is likely to be larger than the biggest slice of the 1% that Linux has.
They also have a willingness to pay for software.
As Dr. House once said, "I guess I've just been cursed with the ability to do the math."
As far as "no one wants to use it on *nix", you are simply poorly informed. Take a gander at the Mono mailing-lists sometime. There are loads of people using Mono for *nix development.
As far as my ability to think for myself, I'd worry about your own thinking ability - clearly you are lacking in that department far more than I.
C.T.: When I decide to start taking advice from someone who so clearly has no idea what he's talking about, I'll let you know - I'm sure you have plenty of useless advice to give me.
Vadi: as I'm sure you know, "killer app" is in the eye of the beholder. I find Banshee and MonoDevelop to be my "killer apps".
I also tend to find it ridiculous to go on about "killer apps" for a particular language anyway. What is C's "killer app"? What is C++'s? How about Python or Java's?
Does any language or runtime really have such a thing as a "killer app"?
I don't think so.
This leads me to conclude that the "killer app" argument is a logical fallacy.
As far as your complaint about this no-named cross-platform app that looks fugly on Linux, I think we can both agree that the world is littered with examples of those no matter what language the app is written in (Java, C, C++, Objective-C, etc - I'm sure someone could find at least 100 examples of each - it is not unique to Mono).
gdamjan: I'm not sure where I ever said Python was useless. Mind pointing it out to me? Or is this just a poor attempt at presenting a strawman?
What RMS said is being ridiculously blown out of proportion, misquoted, misinterpreted, and pretty much mis-everything'ed.
RMS has no problem with Mono, and encourages its development as a way to help non-Free software become Free. He discourages its use in new project development as it has the potential to be attacked by MS. He praises Mono for being an active Free software project, and had good things to say about Miguel.
I actually asked the question which I believe caused all the fuss. After his little talk about Mono, I asked RMS what exactly happened between he and Miguel. That is when RMS told how Miguel was on the board of FSF and was working on proprietary software at the same time, without disclosing this fact to the FSF. Therefore, RMS calls Miguel a traitor (and I believe rightfully so). These comments were *not* related to Mono.
Way too many feathers have been ruffled by such old news. The RMS/Miguel incident occurred a decade ago, and RMS's views on Mono have been public for many years.
Hello Jeffrey,
Just thought I'd drop a line to let you know that as someone who does .NET for a living but has a soft spot for Linux, the efforts being put in by the Mono team are more than appreciated.
Thanks.
> we're interested in making great cross-platform development tools
Fuck you. I don't want a Java 2.0 with a whole new crappy VM which brings new incompatible libraries or whatever. We already have Python, Perl (and Parrot !), Java and many libraries for these languages. Why would we need Mono ?
That being said, I think that C# could replace C for Gnome applications : high-level user apps should be written with high-level tools. But even for that, Vala already exists.
J.S.: This was not an advice. I was just explaining why I dislike Mono.
Non-compiled languages use more resources than compiled languages. According to me this is a hard fact. If you disagree with this, then explain why. But the "you don't know what you're talking about" part is called an ad hominem. And this sidetracks the issue.
Jeffrey,
I would like to reply to this part of your post:
"modern VM technology is already more or less on par with C/C++, and upcoming VM technology is quite likely to exceed the performance of C/C++"
I'm sure that for certain use cases, what you say may be true.
But said in such generality, there's no way that it can be true. It's very simple really: C and C++ do no incur any inherent overhead, while any VM does. In a high-performance setting, you want a programming language that puts you in control of every memory access, of every system call (malloc...), etc. In really high performance settings, what you really want is for the resulting assembly code to be as predictable and controllable as possible. And the possibility of emitting your own inline assembly where you notice that the compiler is otherwise doing something wrong.
C and C++ provide that. A VM doesn't.
An extreme, but very common case is that of real-time embedded systems. Here you have users who have needs like "I need to implement this algorithm in less than 16k of code in total, without doing any system call like malloc, with only one thread running, without any memory overhead". That's 4 separate reason why these people can't use a VM language.
Craig: A traitor just because Ximian had to implement one piece of proprietary software in order to survive? Well, maybe RMS should have instead suggested a business plan that would have worked? Hmm?
You should also note that Ximian open sourced that code as soon as Novell bought us. We did not want to write proprietary software.
That's not being a traitor. That's survival.
RMS is more of a traitor to Free Software than Miguel is. RMS is too angry, too unforgiving and too much of a zealot to be able to convince normal folks of converting to Free Software. He scares most people away. Maybe that's how he really wants it, maybe he really wants it to be an elitist cult (and an elitist _male_ cult by the sounds of his sexist remarks).
Miguel, on the other hand, wants to bring Free Software to everyone and he knows that in order to do so, he has to make temporary compromises. And guess what? It works far better than RMS's approach. Miguel has likely brought far more people to FLOSS than RMS could ever hope to bring over unless he changes his ways.
It's too bad people like you and Richard Stallman don't see that. It's too bad that you are so zealous and so spiteful that you have to attack a man that is doing a better job of helping you reach your goals than you are capable of.
Think about that.
Filip: Glad to hear it!
Maebara Keiichi, to complement what Jeff said: it's also easy and fun! Anyway, if you're afraid of the C# syntax, you can always try Boo (another .NET language), which is a bit more similar to Python.
Hi, I actually still cannot understand what is the problem with Mono. The only thing I heard which worries me is that Mono was until recently/and perhaps still is coming with implementation of MS specific libraries which can possibly be an IP problem later.
Can somebody shed some light on whether it is or it is not the case? I just believe there is not good Mono propaganda on low level explaining that it has no IP problems (if there are not any). Like: Mono is OpenSource implementation of C# specification with great surrounding tools and integrated with OpenSource technologies (dbus,..) and with no patent threat from MS batteries included.
Do not underestimate the first look. Many people are being told that Mono is IP patent threat and better is to leave it alone. However the only way around it is to be pacient and keep explaining (it is like with open source ;))
Also, is it my opinion, or do the Mono apps have high memory requirements?
My mono killer-app is gnome-do.
toto: That was part of the quoted post, and therefor not something that I stated.
As you said, in performance critical sections of code, you do want low level access to things like malloc and hand-tuned assembly. But how often is that really necessary? And even when it is necessary, it doesn't mean you can't P/Invoke a native C or asm routine to do it from C#/Mono.
For people that want to get an application written and go back and optimize the portions that truly need it later, C#/Mono is a great way to go.
Micro-optimizing code in C and asm the whole way through writing an application is not going to get you anywhere fast. In fact, you'll likely go out of business before you even complete the application. Or if you are simply writing it in your free time, you'll likely abandon the project before it is finished.
What's more valuable to an end-user? An application that works but has a few performance problems due to being in a high-level language? Or a handful of C/asm routines in an incomplete project?
As far as your embedded case, sure, but no one ever said that Mono was intended for that. No one is making the claim that C#/Mono are the be-all/end-all of programming languages/runtimes. Certainly not me.
And in the future, as embedded systems get more and more powerful w/ more and more memory, you'll start finding more and more applications that run in a VM. In fact, there's already tons of examples - that's the direction cell phones have been going for quite a while now.
The only things end users care about are:
1. is there an app for that?
2. does it work well?
3. is it affordable?
Apps written in high-level languages written by competent programmers will be out on the market sooner than something written in a low-level language. They will also almost always be more affordable because it took less time and money to produce.
So long as it works reasonably well, people will use it.
stereoit: Every single piece of software, whether it be FLOSS or not, faces possible IP issues.
The people attacking Mono with this nonsense are simply doing so to scare people away from it as if it is unique to Mono. It's not.
Mono takes IP concerns far more seriously than most other projects in FLOSS land.
The "omg the patents!" attacks are just fear mongering, plain and simple.
Microsoft have been kind enough to publish a legally binding document stating that ECMA 334 and 335 are free of patent threats from them.
As far as Mono apps using more memory, that's down to individual applications.
Aaron Bockover once told me that after rewriting Banshee's list widget, he was able to get memory use of Banshee down below Amarok and Rhythmbox.
Just because an app is written in C# doesn't mean it necessarily uses more memory than competing projects. It all depends on the design and implementation of each individual project.
JeSuis: why so nasty? If you don't want to use Mono, don't. No one is trying to force you to use it.
We are simply providing it as an option for the people who do want to use it.
Same as the Python, Perl, Ruby, and Vala developers.
C.T.: While your argument may be true, it is irrelevant.
The same argument can be used against higher level languages like C and C++. Programmers shouldn't use C and C++ because they are higher level and use more resources than assembler. Oh noes!
This is why I said you had no idea what you are talking about. And I'll be sticking with my original conclusion. You've just cemented that fact.
J.S.: This is where it gets interesting. If you like higher level languages, as most people do. Why not use 'D' or implement C#/[insert your favorite non-compiled language here] as a frontend to 'llvm'?
C.T.: From what I've heard about D, it sounds interesting. But it didn't exist when Mono was started and it's not as widely used/popular as C#/.NET.
As far as compiling C# to native code, "there's an app for that". Mono can already do that for a few architectures and is how we manage to work on platforms that disallow JITing (like iPhone).
The problem is that doing so means that you can't take advantage of some of the dynamic features of C# like Reflection, which are really useful.
There are advantages to using high level JITed languages that you just can't do in any natively compiled language. Maybe in the future that will change, but for now it remains true.
To C.T.
I haven't written anything in Mono, yet even I know that their compiler can produce binaries which are 100% pre-compiled machine code just like C does. They call it "ahead of time compilation" see --full-aot compiler option.
http://www.mono-project.com/Mono:Runtime
Ughh I forgot to add: while I generally like Mono, my only concern with it (and Microsoft's .NET as well) is that they add bloat.
Instead of replacing older C/C++ based runtimes they're building on top of them increasing the number of layers and moving parts, but I guess that's the price you have to pay for backwards compatibility. Perhaps the alternative approach was to implement Mono runtime directly on top of the kernel, bypassing GTK/Glib and even libc.
Another one Mono/JVM needs is a tighter integration with operating system's underlying memory manager. When your operating system is left in the dark regarding your actual memory consumption, you end up with these monster processes unable to share read-only data via kernel's memory mapping mechanism. This is why I asked Jeffrey about code sharing in Mono. I believe will only work with AOT compilation though...
In other words yes, I believe in higher level languages and moving away from C, but I also think that existing projects are going half-way: Parrot, Mono, JVM, Python, Ruby - they all, instead of integrating into the OS, built their own little islands (VMs) over-consuming RAM and refusing to talk to each other. This only works for server environments where you have just a handful active applications per server.
J.S: This is interresting. The way I see it whether there is a VM or not, in the end, every instruction is still translated to machine code. So there must be a way to completely get rid of the VM and have all the desired languages features. But as you say, we will see in the future.
Eugeney: code/data sharing works even with the JIT.
With more general purpose VM's like Mono, if more high-level languages targeted it, then more code/data sharing could happen between applications.
The Parrot VM likely isn't generic enough to support a wide variety of languages like the .NET runtime does.
What I think is cool about Mono is that if you want to program in one of the popular scripting languages like Python or Ruby, you can use IronPython or IronRuby.
C.T.: Well, yes, everything still gets translated into machine code in the end, but the problem is with dynamic code generation.
The current natively compiled languages are not good at dynamically generating new code at runtime which is where the problem exists.
One could make the argument that Stallman and the GNU project were 'chasing the taillights' of the commercial Unix vendors of the time as well. I don't really see any difference and there's certainly nothing wrong with trying to provide a free implementation of a popular platform.
The source of our disagreements (Richard and myself) comes from his campaign to regain credit for Linux.
It was OK for a while, until it completely dominated any of his actions.
14 days before launching the Mono project, the board of directors of Ximian allowed me to talk to a few people in advance about our plans, only if they agreed to keep this a secret until the launch.
Richard agreed to keep the announcement secret and to not talk about it until we had done our press release.
But he did not keep his word. On Monday, our press release was going to come out at noon or so (a time that we had told everyone that had been pre-briefed).
The FSF on the other hand decided to come out with its *own* press release announcing the launch of "GNU/Mono" and "DotGNU".
A carefully planned press announcement was ruined by Richard's announcement.
Hence any further communication with Richard from the Ximian board was suspended. The man could not be trusted to keep a secret even when he had agreed and he was too thirsty to stick "GNU" in front of any new projects.
Since this incident I barely talked to Richard and dismissed his continuous requests to "contact XXX and tell him to say GNU/Linux instead of Linux".
Ximian released the Connector in December, the board incident would not take place until February.
Richard might want to rewrite history all he wants, but our communications effectively had ended after his actions with Mono.
Miguel.
For code sharing across multiple processes you need to use Mono's AOT compilation.
What this does is generate shareable code (it is pretty much a variation of ELF) that multiple processes can run.
This is done doing:
mono --aot foo.dll
Miguel.
If mono was never meant to be CLR compatible... Who wrote the winforms layer?
That said I'm aware of the Gtk# components and will be watching the debate carefully, whilst learning c++ to sit next to my c# and python :)
TGM: it's not that Mono is not meant to *also* be compatible, it's just not the only purpose.
Being compatible with Microsoft's implementation has many added benefits, but if Microsoft goes in a direction that we don't want to go, we won't follow.
Windows.Forms is a meant as an aid to developers that want to get their Windows.Forms apps to run on multiple platforms.
For developers writing new applications, we suggest using Gtk# or else a different UI for each platform.
Jeffrey, look at this mess of comments. That'll teach you to repost one of my half-drunken forum comments to your blog. ;) (Yeah, this is elanthis.)
So far as toto's comments, I think you nailed most of it, but I feel like clarifying further. For the majority of use cases, VM technology is quickly approaching and will soon be surpassing C/C++ performance. "Performance" is not equivalent in all cases. I am starting work in the video game industry. We care about performance a lot. Take all the fancy algorithms the rest of CS community pats themselves on the back for pulling off, and do them all many thousands of time per frame at 60 frames per second. That's what we do.
A lot of (irrational) game developers still use C exclusively because they're afraid of the overhead of C++ virtual function calls. These same dummies go and write their own tables of function pointers and think their implementation is magically faster than the C++ compiler's, naturally. Worst of all for both their employees and their end users, however, is that working in C almost forces you to concentrate on micro-optimizations instead of systemic optimizations.
Well-written, high-performance, A-list game engines these days do so many "inefficient" things that make us old-school developers cringe (omg they're copying strings all over instead of using statically assigned numeric ids!?), and yet the modern game engines not only can do so much more than the old game engines, they are faster on modern hardware than the old game engines are on the same machines!
That's where things like VMs and languages like C# come in. They're not there _quite_ yet, but they're close enough that you can get away with implementing an entire engine in C# and have it perform good enough for moderately graphics-intensive games. Give it a few more years when currently experimental technologies become mainstream, and a VM like the CLR will be able to generate JIT-compiled code that outperforms any possible AOT compiled code, because it will be able to do all those micro-optimizations for you on a whole-system level.
Meanwhile, the developer is freed up to focus on system design and systemic performance, which produces overall more efficient engines.
Up until this very post here you wrote, I liked mono.
But I saw that some other guy attacked python with "making shit up as it " goes while at the same time praising Mono.
If this is the prevalent view of mono, then I can avoid it happily.
(continued -- I ramble, and the blog has a low post length limit)
Elitists like to think of C and C++ as superior (or in many cases, they only think of C as superior) because it forces the programmer to think about every last little thing he does. Since the programmer has to hand write every damn tree or list or other data structure, the thought is that the programmer will make better choices and implement the proper data structures. This is total bullshit, of course. The programmers who can't figure out which pre-written data structure to use can't figure out which data structure to write by hand, and they're the same kinds of programmers that couldn't hand-write a decent implementation anyway.
Most of those C/C++ performance fanatics out there don't know a fucking single thing about modern performance and optimization. I still run into a ton of people that actually preach "performance" tricks that HURT on modern computers far more than they help. I had a classmate who wrote pre-calculated tables of sines, cosines, and tangents, because hey that's how id did it when they made Wolfenstein run at amazing frame rates when Ultima Underworld still dragged ass on the same hardware. Lo and behold, though, a modern CPU can just calculate a sine faster than it can pull the value out of even L2 cache.
Then of course people learn the "memory is slow" thing and start doing -everything- in the CPU and avoid memory use like the plague, and end up writing slower code.
The real professionals -- the one who actually know what they're doing -- will all say the same thing: the compiler is smarter than you, the compiler can optimize better than you, and everything you think you know about performance is wrong. When you write "high performance" code in C/C++ you _have_ to profile the hell out of it, verify your assumptions, and then go back and fix most of your optimizations because most of them either don't help as much as you thought they did or actually hurt performance.
A good VM takes that to the next level. Higher level languages allow the compiler to have more information and make more informed decisions. Good VMs can optimize at runtime with data that a C/C++ programmer can only have with countless hours of profiling and tweaking. Good VMs can optimize based on actual circumstance in ways that even the best profile-guarded optimization could never possibly do, e.g. optimize the code for the specific CPU architecture in use.
It's the same as how modern GPUs work. Applications don't ship pre-compiled GPU machine code for their shaders. They ship raw shader source. The driver takes that source and can optimize it for the exact GPU hardware in use. Driver updates mean that the shaders can get faster without having to upgrade hardware and without having to recompile the whole game.
That said, you can look back to toto's comments about tiny embedded real-time platforms. Those are entirely different beasts. You aren't even actually concerned about __performance__ on those machines. You're concerned about entirely different issues. Maximum code size. Latency. The fact that the platform doesn't even have a C# runtime support. Apples and oranges.
Mono, C#, CLR, C, C++, Python... none of these are perfect. Every single platform has strengths and weaknesses. There are many contexts that I refuse to even think about using Mono. There are contexts where I think Python (a language I generally dislike) is most ideal. There are times I truly love working in C++ and times that I despise the language.
Only an idiot hates a given tool for irrational reasons, but only an idiot senselessly advocates the use of a single tool for every circumstance.
shevegen: huh??? You do realize what he was saying is that the Python language grows organically.
That's not Python bashing. There are good and bad things about that.
I swear, some people are *looking* for any excuse they can find to hate Mono and label people who like Mono as Python haters or something. This simply is not the case.
Sean: Thanks for your comments explaining what you meant.
Awesome, awesome info.
Quick question about Evolution: are there plans to port and/or rewrite/redesign Evolution on top of Mono? Evolution is the competent Mail/Calendar/etc client in Linux land to me, but it simply feels HUGE and doesn't do a couple of things I'd like (minimize to tray!)
Benoit: there are no plans to rewrite Evolution in Mono - it would be a huge (expensive) undertaking and likely not worth the effort.
Minimize to tray, then? ;) Keep up the good work
Nice writeup, Sean
Hard to disagree with you anywhere, great arguments!
But on a practical note, I look at Tomboy, which I expect to launch instantly, but it doesn't. It does very little, it is by far the smallest application I am running (not counting Gnome panel applets),
yet it consumes more RAM than Gvim, Nautilus or even Evolution!
The reason? Shared libraries. Tomboy is a mongrel here, excluded from the Gnome party.
All gnome apps (just like OSX Cocoa apps or Microsoft ones) happily reuse the same runtime, loading very little additional code, very quickly.
Programs written in their own VMs feel *exactly* like that: like little virtual computers that you need to boot up prior to using. I have been waiting since 99 for this feeling to disappear, but somehow gigabytes of RAM and gigahertz do not help, with Java this feel of "booting" applications
only got worse over time.
Do not get me wrong: I don't advocate going back to C/Glib. I spent nearly 10 years programming in C++/MFC on Windows. DO NOT WANT THAT.
I am just publicly wondering how come VM implementors are so obsessed with producing "faster than C" benchmarks and fiercely defending their VMs and JIT compilers in regards to CPU performance, yet the question of "virtual computer feel" and outrageous RAM appetites comes up very rarely, yet this is by far #1 reason why VM-based software got stuck in datacenters.
Why can't Linux memory manager be integrated with JVM or Mono VM? Why do we have two layers of "free/used" counters operating ignoring each other, when you can't even tell how much RAM you're using?
Seriously, RAM consumption measurement is something of a black art for no reason. And, again, it prevents VM-based processes from effectively sharing read-only memory pages. Imagine a Linux desktop with 20 processes written in "Mono Proper" - they'll all have their libraries hosted 20 times at different locations, re-filling CPU caches with exact same stuff - that's an example of systemic optimisation which screams
to be applied: when I launch a 2nd version of a Mono app it needs to start up in 0 (zero) time and eat close to 0 (zero) bytes of RAM for its code,
because it's already there.
Language VMs should be implemented not by complier/library writers but by OS kernel developers.
Benoit: I no longer work on Evolution, but that sounds like a reasonable feature request that you should submit to GNOME's bugzilla if it's not already there.
Eugeney: Miguel (aka mdi) would know better, but I suspect that the way you can get around loading the same code/data 20 times (without the need for AOT) is to use a single Mono VM and load each application into an AppDomain (which is part of .NET) instead of running a new VM process per application.
AFAIK, this should work.
*Is to use a single Mono VM and load each application into an AppDomain (which is part of .NET) instead of running a new VM process per application. AFAIK, this should work.*
Correct, but in this case you're effectively reinventing the wheel: the OS kernel is that piece who manages "application domains". As far as I know, Android works in a similar way - only one instance of customized Google JVM manages multiple Java applications.
I am preaching for a good VM team to merge with Linux kernel to achieve precisely the same goal. This would trully be awesome: a garbage-collecting OS kernel with a built-in caching JIT compiler.
This would give me ability to use modern languages and still adhere to UNIX philosophy of small, fast-launching, efficient specialized executables.
I woudl *love* to hear from Miguel and Linus on this. I know it's easy for me to *want* things, but it's much harder for you guys to actually make it happen. Well, kidos for trying!
Very cool article, thanks!
I have nothing against C# (in fact, I spend more than half my time at work coding with it), but I really fail to see how anybody could find C++ a 'pain in the ass' to work with... I prefer it, really - it's clean, efficient and fast, and the new TR1 extensions make it even easier than it used to be. That is, as long as you use nice APIs like Cairomm and Gtkmm - MFC and the like are really not fun to code with.
Stephen: C++ is so huge that it is impossible to know it all. C is much much smaller and therefor much much easier to fully know the language.
Many large scale projects that are written in C++ have rules about which parts of the C++ language spec you can use. Partially this is because of incompatibilities with certain compilers, but it's also because some aspects of the C++ language get very confusing very quickly.
C# is starting to suffer from this problem a little too (imho), but not nearly as bad as C++ atm.
Then you have subtle differences between C and C++ that makes things annoying for people with a C background (like myself and many other GNOME devs).
If you are just writing your own little program in C++ and stick to the parts of C++ that you are comfortable with, it's fine. But as soon as you start getting a bunch of contributors all with varying degrees of understanding of the C++ language and all using random features of the language, you'll find the project's code to get very complicated to read and understand. At least that's been my experience.
I'm a Windows/Mainframe/Java guy who wanted to play around with C# & F# on his Mac. I am astounded at how great Mono is. Everything just works. Mono is a bridge from what I was doing to what I want to learn to do. Thanks.
Hi, I'm not against mono, and I think you're doing a very good job, but I also think some more accurate statement would help your cause.
- What were the problems in C++ you did not have in C? Were their related to GTK bindings? Because it would not be a surprise given the status of GTK code, which has nothing to do with C++ or whatever language, but with the quality of the toolkit.
- "we are succeeding" seems a very strong statement. Succeeding in what? Where are the examples and the details? Any major project, not sponsored by Novell, switched to Mono and ported desktop applications to the linux desktop that previously were Windows only?
Alberto:
The problems had nothing to do with Gtk+. They were just annoyances in the way C++ does things differently from C.
As far as our successes... well, we've had well over 600,000 downloads of Moonlight alone in the past 3 months. There are top-selling video games written entirely in Mono (and more to come). Banshee is amazing. MonoDevelop is amazing. GNOME-Do is amazing. Tomboy is so good, people forked it just to do a line-by-line port to C++. MonoTouch is selling like hotcakes and a lot of iPhone apps are now written using it and it is in demand for Android as well.
A lot of .NET apps written for Windows are also happily running on Linux thanks to Mono, you don't see these successes because often they are apps that are internal to companies and are not ever made public.
I wish I could tell you all about the numerous things written in Mono that I'm sure you use every single day but don't realize it's written in Mono, but unfortunately we have agreements with those software and hardware vendors not to disclose that information.
But even given just the publicly available information on what is written in Mono / using Mono, it's unbelievable that you don't see it as a success.
V interesting
C++ and C are so unproductive...
I have returned to Unix after a 10 year absense and was VERY disapointed with the lack of progress . It seems more difficult and painfull before while C# and windows is far easier.
Anyway i was building a C# based OS form the ground up ( See Mosa /Cosmos) but am now using ucLinux and Mono and will convert drivers and services to C# ( even if just wrappers) . Note the key to this OS is NO C or C++ apps only typesafe and memory safe languages are useable in return there are significant benefits.
Mono based OS SOOOS
To the person who said C# is tedious he must not have used C++ or Java. Though i agree it is tedious compared to afunctional language like oCaml but you CAN run F# under Mono.
Post a Comment