You must be a windows.net programmer if you're worried about that. We build mono as a development platform for use on free software systems: compatibility with the MS runtime is only a nice side effect of implementing a standard. Mono is not in the same position, say, of wine or samba which become pretty much useless unless MS and windows continue to exist. If we'll not be allowed to be compatible with whatever means, we'll just continue developing mono: the only people that are going to be hurt by that are MS and windows programmers.
Instead of telling us not to worry, just give us the facts. The facts are explained in the FAQ: if a patent issue is brought to our attention we'll seek prior art to make the patent invalid. If that fails we'll implement the feature in a non-infringing way. If that's not possible we'll drop the feature.
You'll note that the above has no mention of mono or.net: indeed the same concerns are valid for any piece of software currently written in the free software and proprietary software worlds.
Does mono have a "Mono Forms" kit that lets me do everything that System.Windows.Forms would do, just in it's own way? We use Gtk# for GUI apps (though there are people working on the mono Windows.Forms implementation, too: it should be beta-ready in the next few months).
it always will be faster since CLR "assemblies" prevent the most effective dynamic optimizations. You have no idea what you're talking about. It's the other way around: some of the classloader features in java prevent some dynamic optimizations.
There are proprietary programs that allow that with some limitations already. It's much harder than the other way around because the java VMs would need a lot of code and substantial changes to the JITs teh garbage collectors etc to be able to support C# code. Mono didn't need any java-specific change to be able to run the ikvm JVM.
Mono has an ahead of time compiler, too, so that's kind of a moot point. It's true that GCJ can currently generate code that runs faster than the code generated by the mono jit, but there are some considerations for that: *) they need to fix their ABI and most things will get an additional indirection so it will get slower. *) the code generated by mono is good enough for most tasks. *) in real life code there are many factors involved: mono uses Boehm's libgc in a better way so many things have better memory use (we have fixes we submitted upstream for it, too). The standard library implementation is important, too, and C# allows for more efficient patterns than GCJ could not optimize (like using valuetypes, unsafe code blocks etc). For example you have the misconception that GCJ compiles code and doesn't use a 'slow' VM: this is not true: it very much uses the gcj VM, which may be fast, but it's still a VM. So, overall, GCJ is an interesting approach, worth pursuing by people interested in it. It's still not an alternative to mono and it certainly doesn't prove that mono is not viable:-)
Given than mono can run basically the same java programs as the free java VMs (since they all use GNU classpath and the lib implementation is the limiting factor) and it runs many.net programs out of the box, mono is much more viable than any free software java implementation.
On Java everyone can join the Java Community Process (JCP). Membership is free and every member is entitled to vote and can even run for election.
With mono everyone can actually write the code and submit it for inclusion in Mono or create his own derivative. But this actually requires doing some work, which is considerably harder than writing uninformed opinions on slashdot like your post;-)
What do you mean when you say that Mono is "free" ? I explicitly said "free software", not free: if you don't know what that means in this context you have serious comprehension issues.
If not then I assume you mean it is "open-source", which is confusing since:
* The Mono FAQ page claims to implement the Microsoft.NET development platform which it has no legal right to
Sure, we'll take your uninformed legal advice seriously. It would be funny to know why you think we don't have the legal right to write our own code.
* Mono consists of three separate licenses, one for the C# compliler, one for the runtimes, and another for the class libraries
I see, you have issues counting up the number of licenses: for your own benefit we'll use just one license for the next release, so you don't have to count and get confused.
Secondly, why do I need a Windows version of Mono?
Dude, you first complain that Mono is not cross-platform and then you complain that it is. Anyway, this clearly shows you don't know what free software is about. I suggest you read http://www.gnu.org/philosophy/free-sw.html.
There are issues running Mono on FreeBSD because FreeBSD has broken thread libs. Some of the fixes are in the latests 5.x releases, but there may be still more issues.
What distinct advantages does Mono have over either of these established and supported platforms ?
Contrary to both the JVM and MS.Net, Mono is free software. Mono is also cross-platform, running on Linux, MacOSX, Windows, Solaris and others on at least 5 different processor architectures. And we're rapidly improving to support better server workloads.
I use debian and compile mono from svn every day. Maybe you need to post details of the failure so we can tell you what's wrong in your system (likely you are still using an old automake, maybe you installed a new one, but still use the old one). If you use the packaged tarballs there are no compilation issues on debian.
The whole point is that the local vars are captured so they will exist even after the original method finishes. This is a very powerful pattern, but you'd need to be a programmer to appreciate it.
You're right that.net is not multiplatform. You're wrong about mono, though: mono runs on x86, ppc, sparc, amd64, s390 on linux, solaris, macosx, windows. More ports are in the works, but the above already cover 99% of the computer systems you'd want to run it on.
Mono's goal, indeed its reason for being, is to clone Dotnet. Nope: mono's goal is to provide a good platform for development of apps on free software systems. This is the major goal, since the beginning. It looks like you're a windows programmer that needs a feature in mono to port his work. We accept patches, feel free to contribute.
You are confused and misinformed. Mono's stated goal is to provide great development tools on free software systems. The fact that by being compatible with.net we get tons of software written that runs on mono is just a nice side effect. Besides, mono is both a bridge between old technologies (C code) just as it is a platform to build new apps in a more productive runtime with whatever language you prefer, C#, python, javascript etc. The direction of Mono is decided by the people who code and contribute to it, not armchair whiners.
So your point is c# is better than java at desktop programming because.. it's not java?
No, because mono uses much less memory and C# has delegates and (in 2.0 or in the current mono compiler) anonymous code blocks, which allow for much better code than the ugly patterns you need to use in java (check the memory comparison fro Gtk+ apps
for some numbers and any Gtk# and java-gnome program for the code cleanness issue).
1. Mono is not the only VM technology under Linux. Besides Java implementation. the opensource world has also it's own future VM, named Parrot. And unlike its competitor, Parrot has a real multi-langage design.
Mono is free software and at this point it is in much better shape than Parrot to become the de facto open source VM.
As for a real multi-language design: it's not enough to say that the design is good for multi-language support: it needs to be really that way and an implementation needs to exist to prove it. Currently Mono runs C#, Java, Python, JavaScript, Tcl, Nemerle, Scheme and a few other languages. When Parrot can do the same we may discuss and see what mono can do at that time and see which design is actually better.
Using SSA in the bytecode is an interesting research field. The MS CLR apparently implements (or implemented) it: see references here and there on OptIL. Basically they augmented IL code with SSA annotations, phi functions etc.
I think there are two issues with it. First it requires the compiler writers to understand SSA and emit a correct SSA representation. The less burden is put on the frontends, the better, IMHO, I don't think the perl and python guys really want to deal with those kinds of low-level details.
There are also many security implications, beside the obvious correctness issues if the intermediate code is not in correct SSA form: proving that it is correct SSA may be a significant time sink if the VM has to provide type safety guarantees, for example.
The other issue is that there are several forms of SSA and deciding which one to use and finalizing it in the bytecode may prevent future optimizations opportunities (without re-creating the SSA form which sort of defeats starting with SSA in the first place). There is also the issue of having the SSA form apply to complex opcodes that the jit translates to several internal reprsentation instructions and it may be better to apply the SSA form to the latter instead of to the former coarse opcodes.
Using stack-based or virtual register-based (not the parrot limited register set) is both simple enough for the high level compilers to produce and simple enough for the jit to put in the preferred SSA form, that it's a better choice. Mono takes the stack-based bytecode and turns it into SSA form to perform some of the optimizations: this allows us to adapt the SSA form to new needs as the research community comes up with better tricks in that area. For example, if Java 8-10 years ago would have choosed and finalized a SSA form in the jvm bytecode, that form would be most likely outdated given the research on different and better SSA forms going on the last few years.
Slashdot Mirror
You must be a windows .net programmer if you're worried about that.
We build mono as a development platform for use on free software systems: compatibility with the MS runtime is only a nice side effect of implementing a standard.
Mono is not in the same position, say, of wine or samba which become pretty much useless unless MS and windows continue to exist.
If we'll not be allowed to be compatible with whatever means, we'll just continue developing mono: the only people that are going to be hurt by that are MS and windows programmers.
Instead of telling us not to worry, just give us the facts.
.net: indeed the same concerns are valid for any piece of software currently written in the free software and proprietary software worlds.
The facts are explained in the FAQ:
if a patent issue is brought to our attention we'll seek prior art to make the patent invalid. If that fails we'll implement the feature in a non-infringing way. If that's not possible we'll drop the feature.
You'll note that the above has no mention of mono or
Does mono have a "Mono Forms" kit that lets me do everything that System.Windows.Forms would do, just in it's own way?
We use Gtk# for GUI apps (though there are people working on the mono Windows.Forms implementation, too: it should be beta-ready in the next few months).
it always will be faster since CLR "assemblies" prevent the most effective dynamic optimizations.
You have no idea what you're talking about. It's the other way around: some of the classloader features in java prevent some dynamic optimizations.
Please file bugs about the issues you found at bugzilla.ximian.com if you haven't already, so we can fix them.
There are proprietary programs that allow that with some limitations already.
It's much harder than the other way around because the java VMs would need a lot of code and substantial changes to the JITs teh garbage collectors etc to be able to support C# code.
Mono didn't need any java-specific change to be able to run the ikvm JVM.
Mono has an ahead of time compiler, too, so that's kind of a moot point.
It's true that GCJ can currently generate code that runs faster than the code generated by the mono jit, but there are some considerations for that:
*) they need to fix their ABI and most things will get an additional indirection so it will get slower.
*) the code generated by mono is good enough for most tasks.
*) in real life code there are many factors involved: mono uses Boehm's libgc in a better way so many things have better memory use (we have fixes we submitted upstream for it, too). The standard library implementation is important, too, and C# allows for more efficient patterns than GCJ could not optimize (like using valuetypes, unsafe code blocks etc). For example you have the misconception that GCJ compiles code and doesn't use a 'slow' VM: this is not true: it very much uses the gcj VM, which may be fast, but it's still a VM.
So, overall, GCJ is an interesting approach, worth pursuing by people interested in it. It's still not an alternative to mono and it certainly doesn't prove that mono is not viable:-)
Given than mono can run basically the same java programs as the free java VMs (since they all use GNU classpath and the lib implementation is the limiting factor) and it runs many .net programs out of the box, mono is much more viable than any free software java implementation.
On Java everyone can join the Java Community Process (JCP). Membership is free and every member is entitled to vote and can even run for election.
With mono everyone can actually write the code and submit it for inclusion in Mono or create his own derivative. But this actually requires doing some work, which is considerably harder than writing uninformed opinions on slashdot like your post;-)
What do you mean when you say that Mono is "free" ?
.NET development platform which it has no legal right to
I explicitly said "free software", not free: if you don't know what that means in this context you have serious comprehension issues.
If not then I assume you mean it is "open-source", which is confusing since:
* The Mono FAQ page claims to implement the Microsoft
Sure, we'll take your uninformed legal advice seriously. It would be funny to know why you think we don't have the legal right to write our own code.
* Mono consists of three separate licenses, one for the C# compliler, one for the runtimes, and another for the class libraries
I see, you have issues counting up the number of licenses: for your own benefit we'll use just one license for the next release, so you don't have to count and get confused.
Secondly, why do I need a Windows version of Mono?
Dude, you first complain that Mono is not cross-platform and then you complain that it is.
Anyway, this clearly shows you don't know what free software is about. I suggest you read
http://www.gnu.org/philosophy/free-sw.html.
There are issues running Mono on FreeBSD because FreeBSD has broken thread libs. Some of the fixes are in the latests 5.x releases, but there may be still more issues.
What distinct advantages does Mono have over either of these established and supported platforms ?
.Net, Mono is free software. Mono is also cross-platform, running on Linux, MacOSX, Windows, Solaris and others on at least 5 different processor architectures.
Contrary to both the JVM and MS
And we're rapidly improving to support better server workloads.
Mono is slow and bloated compared with Java.2 005/Fe b-09.html
You obviously didn't measure, see:
http://primates.ximian.com/~miguel/archive/
I use debian and compile mono from svn every day.
Maybe you need to post details of the failure so we can tell you what's wrong in your system (likely you are still using an old automake, maybe you installed a new one, but still use the old one).
If you use the packaged tarballs there are no compilation issues on debian.
Please tell us who whose people are so we can remove their code.
We don't decompile the MS libraries as a rule.
The whole point is that the local vars are captured so they will exist even after the original method finishes. This is a very powerful pattern, but you'd need to be a programmer to appreciate it.
You're right that .net is not multiplatform.
You're wrong about mono, though: mono runs on x86, ppc, sparc, amd64, s390 on linux, solaris, macosx, windows. More ports are in the works, but the above already cover 99% of the computer systems you'd want to run it on.
Mono's goal, indeed its reason for being, is to clone Dotnet.
Nope: mono's goal is to provide a good platform
for development of apps on free software systems.
This is the major goal, since the beginning.
It looks like you're a windows programmer that needs a feature in mono to port his work. We accept patches, feel free to contribute.
You are confused and misinformed. .net we get tons of software written that runs on mono is just a nice side effect.
Mono's stated goal is to provide great development tools on free software systems. The fact that by being compatible with
Besides, mono is both a bridge between old technologies (C code) just as it is a platform to build new apps in a more productive runtime with whatever language you prefer, C#, python, javascript etc.
The direction of Mono is decided by the people who code and contribute to it, not armchair whiners.
You need to use the latest 5.x FreeBSD versions, since the previous had broken thread support.
So your point is c# is better than java at desktop programming because .. it's not java?
No, because mono uses much less memory and C# has delegates and (in 2.0 or in the current mono compiler) anonymous code blocks, which allow for much better code than the ugly patterns you need to use in java (check the memory comparison fro Gtk+ apps for some numbers and any Gtk# and java-gnome program for the code cleanness issue).
Besides Java implementation. the opensource world has also it's own future VM, named Parrot. And unlike its competitor, Parrot has a real multi-langage design.
Mono is free software and at this point it is in much better shape than Parrot to become the de facto open source VM.
As for a real multi-language design: it's not enough to say that the design is good for multi-language support: it needs to be really that way and an implementation needs to exist to prove it. Currently Mono runs C#, Java, Python, JavaScript, Tcl, Nemerle, Scheme and a few other languages. When Parrot can do the same we may discuss and see what mono can do at that time and see which design is actually better.
And I'm sure you filed a bug report about that, right?
> Mono 1.0.2 (--optimize=aot) (**)
You missed the explanation note here. I'll add it for you:
**) I'm an Anonymous Coward who can't read a manpage to check the option to use to enable full optimizations.
BTW: it's -O=all.
Using SSA in the bytecode is an interesting research field. The MS CLR apparently implements (or implemented) it: see references here and there on OptIL. Basically they augmented IL code with SSA annotations, phi functions etc.
I think there are two issues with it. First it requires the compiler writers to understand SSA and emit a correct SSA representation. The less burden is put on the frontends, the better, IMHO, I don't think the perl and python guys really want to deal with those kinds of low-level details.
There are also many security implications, beside the obvious correctness issues if the intermediate code is not in correct SSA form: proving that it is correct SSA may be a significant time sink if the VM has to provide type safety guarantees, for example.
The other issue is that there are several forms of SSA and deciding which one to use and finalizing it in the bytecode may prevent future optimizations opportunities (without re-creating the SSA form which sort of defeats starting with SSA in the first place). There is also the issue of having the SSA form apply to complex opcodes that the jit translates to several internal reprsentation instructions and it may be better to apply the SSA form to the latter instead of to the former coarse opcodes.
Using stack-based or virtual register-based (not the parrot limited register set) is both simple enough for the high level compilers to produce and simple enough for the jit to put in the preferred SSA form, that it's a better choice.
Mono takes the stack-based bytecode and turns it into SSA form to perform some of the optimizations: this allows us to adapt the SSA form to new needs as the research community comes up with better tricks in that area.
For example, if Java 8-10 years ago would have choosed and finalized a SSA form in the jvm bytecode, that form would be most likely outdated given the research on different and better SSA forms going on the last few years.