Slashdot Mirror
Miguel de Icaza Explains How To "Get" Mono
LeninZhiv writes "It's perhaps the most controversial project in the open source world, but this mostly stems from misunderstanding: Mono, the open source development platform based upon Microsoft's .NET framework. Immediate reactions from many dubious Linux developers have ranged from confusion over its connection with .NET to wondering what the benefits of developing under it are. Throughout the course of its four years of intense development, sponsored by Novell, Mono founder Miguel de Icaza has had to frequently clarify the .NET issue and sell the community on it. In this new interview, Howard Wen asks Miguel to explain himself one more time."
About a year ago, I wrote a C# webserver that did basic authentication, cgi, and directory browsing. It had a GUI but I partitioned it so that the webserver wasn't depenent on the GUI interface. I downloaded mono, created a console front end, compiled and ran it. Flawless. I didn't have to change one single line of code in the webserver class. Thats all I need to know. (BTW, this was on a windows box.)
Here we see F-Spot, a photo management application for the GNOME desktop that was developed under Mono.
Here's the homepage for F-Spot, FWIW.
I'm sure I know less than most, but here are my general experiences with it.
.Net C# - The only major difference is mono's lack of complete support for windows.forms. This is windows primary API for building C# gui apps under windows. Mono is working on an implementation of windows.forms, but I personally prefer gtk# which is portable (at least to windows afaik). Also, they have and ASP.net implementation which is suppose to have great compatability but I can not speak from experience here
.net platform. We're talking about ECMA specifications here, so they really can strive for compatability, it's less of (though not completely) a moving target than the WINE people have to deal with. They use to have a page listing package status, I can't seem to find the link anymore.
Mono Vs C++ - this is not a normal comparison due to one being a byte-code language and the other being compiled. That being said, I'm continuously impressed with mono's speed (especially compared to Java). It's current downside is an increase in memory utilization (compared to c, c++).
Mono Vs.
Mono compatability claims - here's the shocker, it really is very compatable with microsoft's C#
Disclaimer: I've been working on various small personal projects using mono for the last 6 months and have been using various apps centerend around mono for about the same.
Fear trumps hope and ignorance trumps both
You mean like this?
No forms at all, gtk or windows. As I said I whipped up a console (cmd line) front end just for the mono test. I should also mention that this webserver was heavily multithreaded - which is another important yardstick for the maturity and stability of their code.
My only gripe was the lack of a decent debugger (monodbg hardly worked then), but it was quite a while ago, and I hope someone would post their experience with a newer version of the debugger.
de Icaza: We are making Linux a fertile ground for third-party developers: we are allowing developers with Windows/.NET expertise to use and distribute software for Linux, easing the adoption of Linux.
> It would be interesting to see how java would perform if a bytcode compiler could be written for it that targeted the Mono CLR.
Like this? Doesn't run AWT or Swing, but oddly it does run Eclipse (or did). Can't say what the speed's like though. Most CLR 1.x bytecode's pretty easy to translate to Java (albeit things like delegates are rough), but the 2.x CLR (Whidbey) is quite a bit different -- generics at the bytecode level, for one.
Programmer productivity is higher in garbage-collected (MS calles them "managed") environments such as Java and .Net/C#.
In addition, it's much harder to make programming blunders such as overstepping the bounds of an array or string, which can in turn lead to security vulnerabilities.
Those two reasons alone are enough to favour a Java/C#-type approach in situations where absolutely bleeding-edge performance isn't a requirement (i.e. almost all of them).
Fine we'll all switch completely to C++.
Just add a garbage collector, remove multiple inheritence, and eliminate the need for header files.
Oh wait, now you have java and C#
Don't just assume that because you like C++ for everything, that everyone else does.
Some things are just easier to do in java or C#.
There are plenty of cases when the bottleneck in your application is something like I/O or bandwith or SQL running time. In cases like these, often the benefit of a super fast GUI doesn't outweigh the rapid development of using something slightly higher level.
C and C++ definetly have their place, but so do java and maybe even C#
Just pick the right tool for the job.
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
I recently had to write a C# interface to OpenLDAP. The easiest way I could find was to use Novell's LDAP library for C#. But it is built on Mono, and I didn't have time to crunch through the thousands of lines of code and rebuild the binary for Microsoft's .NET framework.
Interestingly enough, the only thing I needed was the Mono.Security.dll file, which is referenced from the Novell LDAP binary. So even though the Novell binary and Mono.Security.dll were written and compiled against Mono, having just that one dll in my referenced path allowed me to write my entire app in Microsoft .NET - zero recompiling, zero fuss. Point is, interoperability worked really nicely for me.
Excuse my speling.
Making The Bar Project
Unfortunately almost every GTK app compiled today depends on having gnome daemons running too.
You are talking about gnome apps. True GTK apps like gaim or gimp don't need any gnome daemon running at all. Actually, they even have windows versions.
Don't ask them. Ask the GCC team.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Lol. I love these kinds of conspiracy theories. They completely ignore the facts.
.NET, whether it wants to or not. Longhorn's userland is now largely .NET based (WinFX) making .NET apps first class citizens of the OS. Core Longhorn technlogies such as Avalon and Indigo are written in .NET.
.NET anytime soon.
Microsoft is now wedded to
MS isn't dumping
If you need web hosting, you could do worse than here
Mono really is a godsend in this respect. I have a lot of C# experience, as do the programmers with whom I work - it is a very productive language for medium to large middleware projects. Some of our larger projects require that we lease both the hardware and software stack to our clients, most of whom are non-profits who don't have huge amounts of cash on hand. Windows licensing for a small server could seriously eat into any profit margin when dealing with 50 remote offices (with about 20 users each), without a dedicated net connection (so a web-based app won't help). Mono lets us install a small Debian-based server at each small location, reducing licensing costs to zero - but not requiring that we abandon our existing codebase/installed base by switching to Java. All told, savings can easily run into the tens-of-thousands per larger client, per year.
Lead developer, http://wisptools.net
A C# front-end to Gcc might have some value for compiling programs so unwisely written in that language, but a bytecode interpreter seems just silly.
.NET and Mono. While it's true that the first version of mono was interpreted, no version of MS's .NET ever has been and the most recent version of Mono does not interpret either. It uses JIT compilers to compile code at runtime as it's accessed.
You seem to have a fundamental misunderstanding of
This is actually a nice situation in some ways, since the JIT compiler knows more about the machine's runtime situation than a static compiler can.
For example, it can compile to 64 bit on 64 bit machines with zero changes in the source bytecode. It can also adapt to runtime situations (such as low memory conditions) more easily.
Of course this has the penalty of a slightly less responsive application the first time the code executes, but that's a small price to pay.
If you need web hosting, you could do worse than here
Real world .NET applications are peppered with PInvokes, COM interop, MSSQL / IIS extensions and various other crap which makes the run badly or not at all on Mono. Even the best will in the world won't change this.
WINE might help a bit, but its too bad if you're on a non-x86 platform.
Even Microsoft don't give a damn about portable .NET. Witness their new Enterprise Library which they're pushing on developers. It contains several dozen Win32 calls right there in this common library. Any enterprise app that relies on it will be infected as a result.
It's time for us all to do something about Miguel and Mono.
You sound like a fucking psycho. Really, seek help. You'd swear Microsoft had some secret agenda to wipe you all out in a covert operation.Linux sucks. And you're fat. Take a shower hippy.
Have you tried using Monodoc? We have documented most of the Gtk namespace, and most of the underlying libraries (Gdk, GObject).
There are a couple of missing pieces like the Accessibility Toolkit (Atk) or Pango, but we are working towards finishing it.
Miguel.
Seems fairly simple to intercept those calls and map them to managed code.
We might evaluate interception on a case-by-case basis.
Miguel.
The JIT isn't the issue. The intermediate language is, or rather was, the issue. When Mono was started, GCC used a register-based intermediate language. It is difficult to translate a register-based intermediate language to a stack-based intermediate language.
Look at the GCC/Java backend, which skips the entire register-based intermediate layer; the GCC/Java project basically re-wrote the GCC back-end to avoid the register layer. Because of this, you couldn't compile any GCC-supported language to Java bytecode, such as C, C++, FORTRAN, Ada, because they all targeted the register IL instead of Java's stack-based IL.
See also: Mono's Technical FAQ.
Things are somewhat different as of GCC 4, due to the GIMPLE architecture which should support stack-based architectures such as Java bytecode and CIL. However, GCC 4 didn't exist when Mono was started (it doesn't exist now, except in beta form), so it obviously couldn't be used as part of Mono.
I can't speak to the truth of this, but I can say that I haven't seen any comments from GCC developers on the mono mailing lists regarding the SSAPRE algorithms. I can't think of any messages from a GCC developer on the mono lists, actually...
Another backend was necessary because CIL and Java bytecode are different. Differences are outside the scope of this, but one difference is whether or not types are part of the opcodes -- compare Java's iadd, ladd, fadd, dadd to CIL's add opcode. Generics add a further difference -- compare Java's type erasure to the "baked-in" generics support of CIL.
To support CIL at all, you need to support another backend, just to support the differences between Java bytecode and CIL. Alternatively, you can argue that CIL shouldn't be supported, which would tie .NET developers to Windows without any chance of migrating to another platform.
You're absolutely correct. In the end, .NET apps written on windows will not work on Linux. But .NET apps written on Linux will surely work on windows. How this gives people incentive to move towards linux(as opposed to away from it) I will never understand. I want to see MS write MS Office in .NET so that it runs on linux. You think they'll do that? Yeah Right!
mp3's are only for those with bad memories
C++ is an ISO standard. And you do realize that C#, CLI, and C++/CLI are ECMA standards. And soon to be ISO standards.
EDG is in the process of writing a front end for C++/CLI. The EDG parser is used by Intel, Borland, Comeau, and others. Although C#, CLI, C++/CLI were primarily created by MS, calling them MS technologies is inaccurate.
(Note: .NET/CLR is MS's implementation of CLI. Mono is another implementation of the CLI. Think of it as analagous to JRE in the Java world. Which by the way is not standardized.)
Wow. Says it all really. The fact that you cannot stand VS.Net probably in no way hampered your ability to find the options you like.
I know of at least three refactoring add-ins for C#, one of which (at least) integrates itself directly into the IDE and menus. And thats 30 seconds with Google and not having a clear idea of what refactoring is.
As far as code completion goes, I'm not sure what you thought was missing. Granted I stopped using IDE's for Java back in 2000, so I'm not sure of Eclipse (et al)'s capabilities. I'm fairly certain that automatically finishing what I am typing, automatically doing braces/etc, etc is probably the case though. Or maybe giving you the option to add event handlers (press tab to generate) or the functions the event handlers point to (press tab to generate) or setting up your namespace and class templates, as well as auto-completion (even in HTML view for ASP.Net)...I digress.
Define proper. As far as I can tell the only difference between try/catch/finally in Java and in C# is that classes that throw exceptions must(can? my Java is several versions out of date and rusty) be declared with "throws exception". cascading catches are supported, custom exception objects, no exception object at all for a "catch all", etc. But don't take my word for it, here is google to the rescue again.
As far as the rest of your ill-formed sentance, I think your implying there is VB-syntax code in (or required by) C#. Please to be showing me an example.
Disclaimer: My work desk has a windows and a linux box on it, I abhor ASP.Net, and learned/used Java before C# or VB.Net.
Whee signature.
However, my policy is, if it won't install clear out of yum repository on Fedora Core 3 it's not ready for my use. I'm sorry, I work on my computer. I have better things to do than chasing down dependencies and installing RPMs from untrusted sources. In year 2005 I simply refuse to spend my time on this kind of shit.
So, Miguel, how about putting together a god damn yum repository that contains all required dependencies so that the users of one of the most popular distros would be able to at least try your software, if not "get" it? I remember back in Ximian days the only thing you needed to install Gnome was ssh connection.
The flattened tree is equivalent to the stack-based layout of Java opcodes (since the JVM knows the arity of each method call) so that's just "revisionist naming" practiced in C# and its libraries to not look like a pure rip of Java.
.NET is faster loading but slower at runtime. Check the language shootout for instance.
Assemblies aggressively optimized means they are internally linked ahead of time like a normal DLL, so internal inlining uses static rules. Cross-assembly inlining is also more difficult. Basically
and
the compiler can assert that the underlying object is always of a certain class. This can not be done with bytecode languages
In fact, you have this exactly backwards.
These types of optimizations are exactly the ones that can be done, and are done, in Java.
The Hotspot Java compiler does not "assert that the underlying object is of a certain class". It can actually notice that, hey, this object seems to be of class X at least so far. So maybe it is always of that class. So Hotspot compiles a method that makes that assumption.
Here is the neat trick: if Hotspot's assumption turns out to be wrong, it discards the earlier compilation and recompiles with a looser assumption.
This is done today. It is called dynamic deoptimization. It means that "virtual" function calls can be compiled as direct jumps, and even inlined. If it turns out later that the call really needs to be virtual -> automatic recompilation on the fly and you are good to go again.
Compatibilty checking.
.NET on windows and seeing if it will run in Linux.
Develop Mono on windows there is a better change of having simular compatibility running on Linux vs.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You're right. But there is a trick that the Hotspot optimizer can't do, and that is to recognize the locality of an object, even if it has virtual methods. What the Hotspot actually does is to look up the inheritance tree of a newly loaded class; if the new class overrides methods of another class, and then super class' inline methods are de-inlined and the call becomes virtual. But the Hotspot VM can't tell whether an object is actually virtual or not, because it does not look at the program's graph, but at the class inheritance graph! the whole-optimization technique is able to do that, because it can actually understand that a class is never used in some places, and therefore it can inline some virtual calls. The whole-optimization technique can even inline whole algorithms, even when composed of multiple virtual function calls: it has been shown that it can improve the performance of an app by even a 70%.
Furthermore, the Hotspot optimizer imposes a performance hit. All this monitoring that takes place takes computing cycles off the application. On the other hand, a C++ program is perfectly optimized by the compiler, and it runs without any VM overhead.
I am not saying that bytecode sucks...on the contrary, it's very useful, since the same binary runs on any architecture. It's really important in a business application enviroment. But the argument that Hotspot optimization produces equal or faster code than pre-compiled code is false.
Considering all, Java is slower than C++ for the following reasons:
1) Java does not have stack-based objects. That imposes a performance hit, because the program's heap is literred with many small objects, that will be disposed of at the next collection of generation 0, but will not let those memory pages be swapped out to disk. A C++ program that uses many stack objects is way faster than the comparable Java program, because it makes much better resource management.
2) The nature of the Java language, with everything being derived from class Object, makes every cast dynamic. The Hotspot compiler pauses the program and replaces the dynamic cast with a check if the class is the correct one and no dynamic cast. But the dynamic cast replacement with static cast is done by the C++ compiler during the compilation phase, and the executable runs without any Hotspot overhead. In reality, there are very few points in a Java program where the dynamic cast can be resolved and remain static. Take collections, for example: they can be used in thousands of places in a program. For every collection, there are thousands of places in code that the same casts are de-optimized again and again, in order to fulfill the assumption that the cast may be static. On the other hand, C++ generates different code for each template function, and is able to optimize the code better since primitives can be used in collections. A real example of this is the map class: in C++, key searches in maps (which is an operation that happens at every insertion, removal and search) with integers are hardware-based, with the integer kept in a register, whereas in Java it is an object, which is cast to 'Integer', then the value is obtained by a a virtual call (which may be inlined), then used as an integer value. And the map search loop can be easily be unrolled by the C++ compiler.
Again, I am not saying that Java is useless. Personally, I don't mind my application to be a little slower, while I get a huge increase in productivity. But at the same time, we can not let false conclusions circulating around. Hotspot is nice, but all the pioneering work for compilers is done on the C++ front, and C++ is the leader in performance. It's obvious even to the most naive user that Java apps are slower. It is no accident that no major performance-intensive business application like a Word Processor is written in Java (actually Sun tried it, but it was very slow and unusable).
Yes, the C# of the MS world is MS only which sucks. However, Mono has taken C# to Linux, Windows, Mac, Solaris, FreeBSD and more coming in the next version due this year. The architectures are x86, PowerPC, S390 and SPARC-based systems and the next version coming out is going to have more. There are two 64 bits ports: SPARC v9 with Solaris and the AMD64 port. When Mono 1.2 comes out this year, there won't be any reason for me to use Java really. I personally like C# better and the big thing I _hate_ about Java has always been Java exceptions. Exceptions in C# are much nicer and you are not forced to handle them.
I have also noticed a huge advantage to Mono/.Net when it comes to memory footprint. When I run Java apps the memory usage gets high and the virtual memory usage gets really high. I love the Azureus program, however it always causes my MS Windows box to start hitting the swap file and MS Windows sucks at swap file usage compared to Linux so I am always forced to use Azureus under Linux. When I run C# apps, be it with Mono under Linux or MS .Net under MS Windows, the memory foot print is much smaller and swap is almost never used.
The last two GUI apps I have written have been in C# and they have at least the same startup time if not faster than a similar Java program and the memory foot print doesn't even come close to being as high as a similar Java program would be.
I don't want to sound as if I hate Java, because as I have said, I use both Java and C# and like them both. I have used some really nice Java apps that do things to keep the memory foot print down like IntelliJ IDEA. However, even with great programs like IntelliJ IDEA, the virtual memory still gets way up there due to the JVM.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison