For the first time in Mono's history our C# compiler and its supporting engine and core libraries were done before Microsoft released the product, we were usually one to two years behind. This time we are some five months ahead of time:
And Google uses a mix of languages and tools: different features require different tools and all that. Had there been no legal problems, it would have been a no-brainer to use.NET over other technologies.
It did not have to be Mono, it could have been a third party.NET implementaion.
Microsoft claims that they have patents had a chilling effect on Mono adoption.
That does not mean that I do not stand 100% by our position in the Mono project regarding patents. To begin with, we think it is a bullshit argument, since everything you use is infringing on someone else's patents (Microsoft included).
Microsoft like any other corporation will do a cost/benefit analysis of suing someone over patents. So far the kernel has been a juicier target than Mono has.
As the other poster said, the fact that we do not have 1:1 parity has never been a problem.
Some other technologies that are subsets and are wildly successful:
* Android's Java is not a 1:1 mapping to Java either, and that has not prevented it from being successful. * iPhoneOS is not MacOS 1:1, and yet, it is incredibly successful. * Chrome the browser, does not have every feature of Firefox, that did not stop it either. * JBoss is a subset of the full J2EE stack, and for years it has been wildly successful. * Linux for years was not even POSIX compliant, and yet, many of us jumped on it, and it became wildly successful.
In Mono we implement what makes sense, and what people are actually using in day to day applications, we do this using metrics that we obtain from our Mono Migration Analysis that helps us identify which APIs are used, by how many applications and we have collected this data from some 10,000 applications:
Call this the data-driven prioritization of development.
Mono was born as a technology to bring the best that.NET had to offer to Linux, this was initially the c# language and the core libraries. As time went by, Mono evolved in two directions:
(a) Organica growth: as the Mono community grew, we identify missing features, we envisioned better ways of doing something and created tools, APIs, languages and extensions that mattered to us. In this category you can find things like Gtk#, Taglib#, Cairo#, Cecil, Mono.Options, Mono.Security, Mono.Data, Mono.Math, Mono.Management, Mono's C# REPL, Mono's SIMD extensions, Mono's large array support. Mono's dynamic JIT extensions, Mono's static compiler and much more.
For instance, today, more than 350 applications on the AppStore and 10 of the top 100 apps in there are built using Mono.
(b) Better compatibility with.NET: this is a simpler process than coming up with our own APIs. The.NET APIs are documented, there are thousands of applications to test the implementation against, the community is fed directly from the largest middleware stack in the world, so it made sense for us to implement these pieces.
Is it correct that we do not have a full implementation of.NET, there are a few reasons for this, now with numerals:
(i) Some APIs are Windows specific, and makes no sense to bring to Linux, in particular things like System.Management which is a thin wrapper around WMI. Our advise: replace that code with Linux and MacOS specific code and use one or the other at runtime.
(ii) Some APIs are too larger for us to take with our current community. This includes things like WPF and Workflow. If someone steps up, we will embrace them, but until that happens, we are focused on improving the other areas that have more users and that we have more requests to implement. Additionally, the WPF "lite" is a killer stack (also known as Silverlight).
(iii) Focus, we do not want to spread ourselves too thin.
As for.NET 4.0: we are not too far from having the core be 4.0 compliant, it is a nice upgrade to the solid 3.5 release. For instance, our C# compiler is already a full C# 4.0 compiler, and we already provide features that Microsoft wont offer until 5.0 (embeddable, reusable compiler, see C# REPL).
Moonlight is behind Silverlight, but I am not driven by despair, I am driven by the world of possibility. If I were driven by despair, I would not have written a single line of code.
If Silverlight never succeeds, then who cares how behind Moonlight is. But if Silverlight succeeds, and Linux users want to access that content, but the feature is either broken, not implemented or missing in Moonlight, those users will be in a position to contribute the code, and everyone wins.
We removed the GPL code in MonoDevelop for a couple of reasons:
(a) to allow it to become a platform that third-party plugin and add-in developers can target. (b) to allow us to consume open source code that would otherwise conflict with the GPL (MS-PL licensed code, Apache licensed code, and original BSD licensed code).
Notice that (a) is the norm for Eclipse and Visual Studio, and that the ecosystem of third party plugins relies on this, both Eclipse and Visual Studio would be severely limited if they limited the plugins to be all GPL licensed. As I explained on the blog post, there are current users that need to run their non-GPL code inside the IDE.
We want more third party developers to target MonoDevelop, and we want these third parties to consider MonoDevelop a platform that they can target without forcing a license on them. Similar to how the Linux operating system can run code licensed under any license.
The second reason is just a practical one. In the.NET open source ecosystem there are plenty of libraries and tools available under the MS-PL, Old and New BSD and Apache 2 licenses and we want to be in a position to use those libraries without rewriting it. We already do, and it has saved us a lot of time.
Various pieces from "olive" graduated into main Mono in the past year, including WCF, LINQ to Objects, LINQ to XML and WindowsBase (they are all in Mono 2.6)
The missing pieces (Workflow Foundation and Presentation Foundation) are not part of our plan.
As for CodePlex: it turns out that there are two entities: CodePlex.ORG (owned by the Foundation) and CodePlex.Com (Owned by Microsoft, and has no affiliation with the foundation).
It is beyond unfortunate that the Foundation adopted the name from the hosting site. The logic apparently was "It is already a known brand". In my opinion, moving ahead with this name was a terrible decision as it is incredibly confusing, a point that I have raised with the board of directors.
The CodePlex foundation has no control over the contents of CodePlex.com.
The allies I refer to are folks like Linus, Eric Raymond, Tim O'Reilly and everyone else that advocates the same ideas, but does not take marching orders from him.
Not many sites used Silverlight 1.0, because to begin with, barely any sites used Silverlight 1.0.
1.0 did not include the.NET runtime, for most people it was just a javascript plugin that did audio and video. Silverlight only became interesting with 2.0 (this is what we were drawn to when Silverlight 1.1 was announced).
Folks have three options for Silverlight on Linux: (a) Hope that Microsoft supports it. (b) Ignore it altogether and hope it vanishes. (c) Support Moonlight.
We have taken the third step as we believe it will gain adoption and Silverlight will be required to access certain web sites in the future. You might disagree and hope for (a) or (b). In the meantime, we have initiated a collaboration with Microsoft where they provide us with licensed codecs and test suites for all of Silverlight (.NET, GUI, video, audio, streaming) to make sure that the open source version of Silverlight is compatible.
Although we had early access to 2.0 and 3.0, we only use this knowledge for planning. Once they go beta, we have used the public information to add some of those features to Moonlight as we go. For example Moonlight 1.9.5 is actually a mix of Silverlight 2.0 and 3.0, it already supports some four or five features from Silverlight 3.
But Silverlight is a large project, and we are a small team compared to the task at hand, so you are right that we will continue to lag behind Silverlight. This trend in my opinion will change when the fundamental principle of open source kicks in: the need to scratch and itch.
Most Linux users have not had a compelling reason to use Moonlight other than for example Moonshine, but as Silverlight continues to gain adoption and more sites require it, we expect open source contributors to join our effort to tune, improve, bug fix and implement the features on time.
Although you might want to portray having an open source version of Silverlight as a "a losing game", we see this as fundamentally important for Linux to continue to have access to the best technologies.
Which is why Microsoft has given us access to all of their test suites for Silverlight and the.NET runtime used in Silverlight to ensure that Moonlight is compatible with their implementation.
The difference is that Silverlight code is CIL bytecode that runs inside a sandbox.
ActiveX was native code, and you only had two options: to trust or to not trust, but once you installed the code, the executable had as many rights on your system as any other application running with your user ID.
Silverlight (and Moonlight) come with a sandbox that limits what the code that you download can do, for instance, they do not get direct access to any of your files.
I cant be incompetent and at the same time succeed in derailing Linux application development. Pick one.
Your rage prevents you from making a cogent argument though; I did not "derail" any application development, if anything, I created a project that many people seem to enjoy using.
The fact that you can not tolerate that others do as they please, and that you feel that people need to obey is merely a manifestation of your fascist tendencies.
Both the JVM and the CIL engines can be used to run any programming language you want. They are both turing complete systems, so there is not really anything that will prevent you from targeting any language to run on top of either one of them.
The difference is that the JVM was designed for Java, and Java only.
The CLI originally ran a variation of C++ (they internally called it SMC, or "Smack") and later they created C# and retargeted VB to run on top of it.
But even before this went public, they launched an effort called "Project 7". The goal of this group was to port 7 proprietary languages and 7 research/open source languages to the CIL engine and learn from the exercise what changes were required to make the implementation more efficient. A large number of changes went directly into.NET 1.0, and they allowed the CIL to be a more efficient runtime for running C, C++, Eiffel, Fortran and Cobol than the JVM could. Direct memory manipulation, arbitrary vtable layouts, tail call optimizations all went into.NET 1.0
With.NET 2.0 a new round of languages was tried. The research on ILX and OCaml (mostly using F#) was introduced into the virtual machine, making generic types first-class citizens in the VM, not just entities that were emulated (as they remain to this day in Java). The feedback from Eiffel lead to the introduction of covariance and contravariance in the virtual machine, another feature missing from Java.
The work from Jim Hugunning on IronPython also drove the adoption of new low-level APIs that assisted the runtime in better supporting dynamic languages, all of these features appeared in.NET 2.0 and 3.5.
So certainly, you can target anything into anything else, at the end of the day, everything is running on top of some CPU. The difference is that with.NET you have to jump through less hoops, and the runtime is richer for language developers.
So in Java you can certainly emulate pointers and malloc for building a C compiler. The emulation will tkae the form of "Allocate big array, and emulate pointer operations there". Possible, but not very efficient.
Generics is another area that helped languages like C# get generics that actually make sense, and do not require a PhD to understand. This is an important difference: in Java generics are emulated, in C# they are native to the environment.
That being said, if you like Java, by all means, keep using Java.
Additionally, there are some glorious bindings for Qt called Qyoto now.
The Qyoto bindings power the very pretty Synapse IM client, it is worth taking it out for a spin, because the author has gone the extra mile to make his application good looking and very smooth:
Slashdot Mirror
Not .NET, but close enough and open source for Solaris, Linux and Mac downloads is available here:
http://www.go-mono.com/mono-downloads/download.html
We have announced that our upcoming Mono release (2.8) will default to 4.0:
http://www.mono-project.com/Roadmap
For the first time in Mono's history our C# compiler and its supporting engine and core libraries were done before Microsoft released the product, we were usually one to two years behind. This time we are some five months ahead of time:
http://tirania.org/blog/archive/2009/Dec-09.html
There are still a handful of loose ends here and there, but luckily, nothing major.
.NET was released in July of 2000.
And Google uses a mix of languages and tools: different features require different tools and all that. Had there been no legal problems, it would have been a no-brainer to use .NET over other technologies.
It did not have to be Mono, it could have been a third party .NET implementaion.
Rather, submit patches to replace System.Data with Sqlite-net and you have protection from Microsoft patents on .NET
You are mixing two different things.
Microsoft claims that they have patents had a chilling effect on Mono adoption.
That does not mean that I do not stand 100% by our position in the Mono project regarding patents. To begin with, we think it is a bullshit argument, since everything you use is infringing on someone else's patents (Microsoft included).
Microsoft like any other corporation will do a cost/benefit analysis of suing someone over patents. So far the kernel has been a juicier target than Mono has.
I provided some context to the SD times article on my blog today:
http://tirania.org/blog/archive/2010/Mar-25.html
Miguel.
Perhaps you need to read the GPL FAQ:
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
As the other poster said, the fact that we do not have 1:1 parity has never been a problem.
Some other technologies that are subsets and are wildly successful:
* Android's Java is not a 1:1 mapping to Java either, and that has not prevented it from being successful.
* iPhoneOS is not MacOS 1:1, and yet, it is incredibly successful.
* Chrome the browser, does not have every feature of Firefox, that did not stop it either.
* JBoss is a subset of the full J2EE stack, and for years it has been wildly successful.
* Linux for years was not even POSIX compliant, and yet, many of us jumped on it, and it became wildly successful.
In Mono we implement what makes sense, and what people are actually using in day to day applications, we do this using metrics that we obtain from our Mono Migration Analysis that helps us identify which APIs are used, by how many applications and we have collected this data from some 10,000 applications:
http://go-mono.com/momareports/
Call this the data-driven prioritization of development.
Mono was born as a technology to bring the best that .NET had to offer to Linux, this was initially the c# language and the core libraries. As time went by, Mono evolved in two directions:
(a) Organica growth: as the Mono community grew, we identify missing features, we envisioned better ways of doing something and created tools, APIs, languages and extensions that mattered to us. In this category you can find things like Gtk#, Taglib#, Cairo#, Cecil, Mono.Options, Mono.Security, Mono.Data, Mono.Math, Mono.Management, Mono's C# REPL, Mono's SIMD extensions, Mono's large array support. Mono's dynamic JIT extensions, Mono's static compiler and much more.
For instance, today, more than 350 applications on the AppStore and 10 of the top 100 apps in there are built using Mono.
(b) Better compatibility with .NET: this is a simpler process than coming up with our own APIs. The .NET APIs are documented, there are thousands of applications to test the implementation against, the community is fed directly from the largest middleware stack in the world, so it made sense for us to implement these pieces.
Is it correct that we do not have a full implementation of .NET, there are a few reasons for this, now with numerals:
(i) Some APIs are Windows specific, and makes no sense to bring to Linux, in particular things like System.Management which is a thin wrapper around WMI. Our advise: replace that code with Linux and MacOS specific code and use one or the other at runtime.
(ii) Some APIs are too larger for us to take with our current community. This includes things like WPF and Workflow. If someone steps up, we will embrace them, but until that happens, we are focused on improving the other areas that have more users and that we have more requests to implement. Additionally, the WPF "lite" is a killer stack (also known as Silverlight).
(iii) Focus, we do not want to spread ourselves too thin.
As for .NET 4.0: we are not too far from having the core be 4.0 compliant, it is a nice upgrade to the solid 3.5 release. For instance, our C# compiler is already a full C# 4.0 compiler, and we already provide features that Microsoft wont offer until 5.0 (embeddable, reusable compiler, see C# REPL).
Moonlight is behind Silverlight, but I am not driven by despair, I am driven by the world of possibility. If I were driven by despair, I would not have written a single line of code.
If Silverlight never succeeds, then who cares how behind Moonlight is. But if Silverlight succeeds, and Linux users want to access that content, but the feature is either broken, not implemented or missing in Moonlight, those users will be in a position to contribute the code, and everyone wins.
Very happy to hear that!
I can only hope we will continue to improve Mono and MonoDevelop.
We removed the GPL code in MonoDevelop for a couple of reasons:
(a) to allow it to become a platform that third-party plugin and add-in developers can target.
(b) to allow us to consume open source code that would otherwise conflict with the GPL (MS-PL licensed code, Apache licensed code, and original BSD licensed code).
Notice that (a) is the norm for Eclipse and Visual Studio, and that the ecosystem of third party plugins relies on this, both Eclipse and Visual Studio would be severely limited if they limited the plugins to be all GPL licensed. As I explained on the blog post, there are current users that need to run their non-GPL code inside the IDE.
We want more third party developers to target MonoDevelop, and we want these third parties to consider MonoDevelop a platform that they can target without forcing a license on them. Similar to how the Linux operating system can run code licensed under any license.
The second reason is just a practical one. In the .NET open source ecosystem there are plenty of libraries and tools available under the MS-PL, Old and New BSD and Apache 2 licenses and we want to be in a position to use those libraries without rewriting it. We already do, and it has saved us a lot of time.
Various pieces from "olive" graduated into main Mono in the past year, including WCF, LINQ to Objects, LINQ to XML and WindowsBase (they are all in Mono 2.6)
The missing pieces (Workflow Foundation and Presentation Foundation) are not part of our plan.
I work on Mono, because I like it. If you want to learn more about my goals, you can read this old post:
http://www.mono-project.com/Mailpost:longreply
As for CodePlex: it turns out that there are two entities: CodePlex.ORG (owned by the Foundation) and CodePlex.Com (Owned by Microsoft, and has no affiliation with the foundation).
It is beyond unfortunate that the Foundation adopted the name from the hosting site. The logic apparently was "It is already a known brand". In my opinion, moving ahead with this name was a terrible decision as it is incredibly confusing, a point that I have raised with the board of directors.
The CodePlex foundation has no control over the contents of CodePlex.com.
The reason is very simple: I am not responding to RMS's opinions on Mono.
I am responding to RMS's last post which is pretty much content free, but does contain another personal attack against me.
The allies I refer to are folks like Linus, Eric Raymond, Tim O'Reilly and everyone else that advocates the same ideas, but does not take marching orders from him.
Not many sites used Silverlight 1.0, because to begin with, barely any sites used Silverlight 1.0.
1.0 did not include the .NET runtime, for most people it was just a javascript plugin that did audio and video. Silverlight only became interesting with 2.0 (this is what we were drawn to when Silverlight 1.1 was announced).
Folks have three options for Silverlight on Linux:
(a) Hope that Microsoft supports it.
(b) Ignore it altogether and hope it vanishes.
(c) Support Moonlight.
We have taken the third step as we believe it will gain adoption and Silverlight will be required to access certain web sites in the future. You might disagree and hope for (a) or (b). In the meantime, we have initiated a collaboration with Microsoft where they provide us with licensed codecs and test suites for all of Silverlight (.NET, GUI, video, audio, streaming) to make sure that the open source version of Silverlight is compatible.
Although we had early access to 2.0 and 3.0, we only use this knowledge for planning. Once they go beta, we have used the public information to add some of those features to Moonlight as we go. For example Moonlight 1.9.5 is actually a mix of Silverlight 2.0 and 3.0, it already supports some four or five features from Silverlight 3.
But Silverlight is a large project, and we are a small team compared to the task at hand, so you are right that we will continue to lag behind Silverlight. This trend in my opinion will change when the fundamental principle of open source kicks in: the need to scratch and itch.
Most Linux users have not had a compelling reason to use Moonlight other than for example Moonshine, but as Silverlight continues to gain adoption and more sites require it, we expect open source contributors to join our effort to tune, improve, bug fix and implement the features on time.
Although you might want to portray having an open source version of Silverlight as a "a losing game", we see this as fundamentally important for Linux to continue to have access to the best technologies.
As with VC1 that are distributed with Moonlight use, the H.264 codecs will be fully licensed from MPEGLA.
Same goes for Moonlight, which is covered explicitly under the covenant not to sue from Microsoft.
Moonlight will have H.264, but we are working towards our first beta of Moonlight 2.0
They understand that quite well.
Which is why Microsoft has given us access to all of their test suites for Silverlight and the .NET runtime used in Silverlight to ensure that Moonlight is compatible with their implementation.
The difference is that Silverlight code is CIL bytecode that runs inside a sandbox.
ActiveX was native code, and you only had two options: to trust or to not trust, but once you installed the code, the executable had as many rights on your system as any other application running with your user ID.
Silverlight (and Moonlight) come with a sandbox that limits what the code that you download can do, for instance, they do not get direct access to any of your files.
Other customers of Redmonk include:
Tier 1:
IBM, Sun, Adobe, Canonical
Tier 2:
Dell, Eclipse, HP, Red Hat, Intuit, Microsoft, Nortel.
From:
http://redmonk.com/clients/
But I guess fact finding might have ruined a perfect rage moment.
You do get LINQ, we have supported it for about 10 months now in production (starting with Mono 2.0).
We are missing LINQ to SQL, but it will be bundled with our next release (Mono 2.6) or you can get it from the dbLINQ project today.
Right, "Type Erasure" means that none of the semantic information is preserved in the produced bytecode or metadata.
This has several problems, for example, the following is invalid in Java:
class Stack {
T [] storage;
Init ()
{
storage = new T [20];
}
}
You might want to read "Generic Gotchas" for Java. There is no such problem with the C# version as they are first class citizens:
http://www.ibm.com/developerworks/java/library/j-jtp01255.html
The implementation is so arcane that it requires documents like this encyclopedic FAQ:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Or even Sun's Ken Arnold stating that "Generics are a mistake":
http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html
None of this problems happen in C# and .NET.
I cant be incompetent and at the same time succeed in derailing Linux application development. Pick one.
Your rage prevents you from making a cogent argument though; I did not "derail" any application development, if anything, I created a project that many people seem to enjoy using.
The fact that you can not tolerate that others do as they please, and that you feel that people need to obey is merely a manifestation of your fascist tendencies.
Both the JVM and the CIL engines can be used to run any programming language you want. They are both turing complete systems, so there is not really anything that will prevent you from targeting any language to run on top of either one of them.
The difference is that the JVM was designed for Java, and Java only.
The CLI originally ran a variation of C++ (they internally called it SMC, or "Smack") and later they created C# and retargeted VB to run on top of it.
But even before this went public, they launched an effort called "Project 7". The goal of this group was to port 7 proprietary languages and 7 research/open source languages to the CIL engine and learn from the exercise what changes were required to make the implementation more efficient. A large number of changes went directly into .NET 1.0, and they allowed the CIL to be a more efficient runtime for running C, C++, Eiffel, Fortran and Cobol than the JVM could. Direct memory manipulation, arbitrary vtable layouts, tail call optimizations all went into .NET 1.0
With .NET 2.0 a new round of languages was tried. The research on ILX and OCaml (mostly using F#) was introduced into the virtual machine, making generic types first-class citizens in the VM, not just entities that were emulated (as they remain to this day in Java). The feedback from Eiffel lead to the introduction of covariance and contravariance in the virtual machine, another feature missing from Java.
The work from Jim Hugunning on IronPython also drove the adoption of new low-level APIs that assisted the runtime in better supporting dynamic languages, all of these features appeared in .NET 2.0 and 3.5.
So certainly, you can target anything into anything else, at the end of the day, everything is running on top of some CPU. The difference is that with .NET you have to jump through less hoops, and the runtime is richer for language developers.
So in Java you can certainly emulate pointers and malloc for building a C compiler. The emulation will tkae the form of "Allocate big array, and emulate pointer operations there". Possible, but not very efficient.
Generics is another area that helped languages like C# get generics that actually make sense, and do not require a PhD to understand. This is an important difference: in Java generics are emulated, in C# they are native to the environment.
That being said, if you like Java, by all means, keep using Java.
Additionally, there are some glorious bindings for Qt called Qyoto now.
The Qyoto bindings power the very pretty Synapse IM client, it is worth taking it out for a spin, because the author has gone the extra mile to make his application good looking and very smooth:
http://eric.extremeboredom.net/2009/03/15/336