7 ms·

Mono: What we are Cooking

72 points by rayvega 16y ago

grav1tas 16y ago
I poke in on Mono from time to time to see what's new there, and I probably don't do it enough. It seems like every time I show up they've finished what they were doing previously and a rolling into a host of other new things. These guys are freakin' rock stars at this stuff. In light of the fact that Java's future has a lot of people flummoxed, it might be interesting to see if there's increased entry into Mono. Are there any good general numbers on the type of use Mono is getting these days? I'd never expect to see some kind of mass exodus from Java or the JVM, but all these new language features and paradigms going into mono are just SO COOL. In the face of how long it took Java 7 to get rolling, Mono seems incredibly nimble to me, but at the same time it also doesn't have that rock solid feel that I get when I think about developing on the JVM. Mad props to these guys, the just never seem to get tired.
- bad_user 16y ago
  MonoDevelop gives me that feeling too, that's why when I did a small project with Mono I went to my trusted toolchain ... Emacs / Rake. Debugging is also painful; I'm still waiting for something like Python's debugger. On the other hand I trust that I'll get shit done with my favorite platforms (Python / Ruby / Linux) more than I trust Java, even though these are considered toys by other people, so it's a matter of personal preference / perspective.
- nodata 16y ago
  If Oracle can't be trusted with Java, can Microsoft be trusted with Mono?
  - tomaszkubacki 16y ago
    Yes, since Microsoft Community Promise http://www.microsoft.com/interop/cp/default.mspx http://www.microsoft.com/interop/cp/default.mspx covers C# Language Specification
  - bad_user 16y ago
    That's a silly question to ask because while these companies may look and sometimes behave the same, their relationships with the community are different. Just as in real-life, the best way to tackle this is to: a) when trust is involved, and you got screwed, the first thing you do is to end any relationship you have with that person / company and tell your friends about it. This sends a clear message which forces other people / companies to reassess their values (i.e. what's more important for your neighbor: you or your parking spot) If Oracle were to lose customers on this, I'd bet they would think twice before ditching ASF / Harmony. b) for people / companies that cannot be trusted, deals are sealed with contracts that are legally binding. In the case of SUN/Oracle: Apache warned everyone about the inability to implement a third-party open-source Java and OpenJDK was just a distraction from the real issue, which shows just how gullible we are (yeah, software developers never read the fineprint). In the case of C#/.NET ... at least the language, the core library and the CLR are real ECMA / ISO standards, there's also a patents grant that doesn't prevent supersets, and there is no TCK or fields-of-use restrictions to speak of. Some people say that these standards do not include important pieces of infrastructure like ASP.NET, WPF or Windows Forms: I say that's a feature, because you wouldn't want to carry that bloat to whatever platform you're targeting (like mobile phones). Just imagine MFC being part of the C++ specifications.
    - gnufreex 16y ago
      Apache != open source Apache wants Java under ASL, Oracle/sun don't want competitors forking their code and making proprietary. That's why Sun chose GPL. No fine-print, just GPL. You can make 3rd party implementation based on OpenJDK and get TCK. Red Hat did it with Iced Tea.
      - bad_user 16y ago
        Oracle/sun don't want competitors forking their code and making proprietary. That's why Sun chose GPL. That's the biggest bullshit I ever heard. And no, you can't make 3rd party implementations based on OpenJDK: the European Commission, when investigating the issue of MySQL being sold to Oracle, concluded that derivate works from GPL v2 licensed code are not protected from patents. That's because the "implicit" patents grant in GPL version 2, while it may hold in the US, it wasn't properly tested in court, and it is too weak for the European Union. Actually this loophole is the "raison d'etre" for GPL ver.3 (the other issues, like tivoization, appeared later). If SUN would have chosen the Apache License or GPL ver 3 (which was already available at that time) this wouldn't have been an issue. Thank you for proving my point ;)
  - tzs 16y ago
    Generally yes. Mono can be split into three parts. First, there are the parts that implement the ISO/EMCA standards for C#, the runtime, and the libraries. Second, there are additional libraries that are in .NET for doing various non-portable things on Windows (like writing Windows GUIs), for which Mono has made compatible libraries for non-Windows. Third, there are additional non-Windows things Mono has added. Some of these are new language features from versions of .NET that haven't yet went through ISO/ECMA. Others are things that Mono has added that don't have anything corresponding in .NET. For items in the first part, Microsoft had to make any IP of theirs known to be necessary to implement the standard available on reasonable terms. The terms they used are the Microsoft Community Promise. For items in the second part, there may be some risk. The simplest thing to do is avoid those parts. For example if you want to write a program that needs to be portable to Windows, Mac, and Linux then instead of using the Windows-specific GUI stuff and Mono's compatible versions of those, use Mono's GTK#. That works on Windows. If you aren't trying to write a portable program, then there is even less reason to consider the Windows-specific stuff and its Mono equivalents. For items in the third part the risk seems low. Mono isn't using Microsoft code for the most part (and any Microsoft code they are using was released by Microsoft under the Apache 2 license which includes a strong IP grant), so copyright isn't going to be a problem. The potential problem would be patents. However most of the things in the third part are things that are also done in many other languages/runtimes and so any patents on the .NET versions are likely covering specific implementation details. There's no particular reason to believe that Mono's independent implementation would have used the same methods. In other words, for these things the risk that Microsoft would go after Mono is about the same as the risk that Microsoft would go after Java, or Perl, or Ruby, or Python for how those languages and runtimes do similar things. Actually, that's not quite right--the risk is probably lower, because Microsoft has provided encouragement for Mono. That's going to raise some estoppel arguments. They'd have less of a problem going after some other language where they might not have as many estoppel issues to deal with. Really, though, the big difference between Microsoft and Oracle here is attitude. Microsoft had encouraged independent and open source work on .NET. They've released quite a bit of their code under the Apache 2 license, including the .NET Micro Framework. The Apache 2 license has a strong patent grant. Sun/Oracle on the other hand have been reluctant to allow truly independent implementations of Java. They will not place the spec under control of a standards body. You can't get a patent license for an independent implementation unless you pass the TCK, and you can't get a license to the TCK under acceptable open source terms. Sun did release OpenJDK, but it is GPLv2. No explicit patent grant. There is probably an implicit patent grant but no one knows what the boundaries are, so the practical effect is that OpenJDK is likely to just track closely Oracle Java. I doubt you'll see any major effort to fork OpenJDK and add Java ME support for instance. A good illustration of the attitude difference can be seen with F#. The F# compiler did not initially work under Mono. Microsoft could have ignored that, opting to keep F# as a reason to encourage people to go with Windows and Microsoft's developer tools, and leave it to the Mono people to enhance Mono to be able to handle F#. Instead, Microsoft quickly updated F# to make the compiler work on Mono. If some Oracle thing didn't work on a non-Oracle JVM, I would be surprised if Oracle would leap in to make it work unless some big customer with a lot of money wanted it.
  - Stasyan 16y ago
    But Microsoft is not in charge of Mono, plus Microsoft is applying Community Promise to Mono (http://www.microsoft.com/interop/cp/default.mspx http://www.microsoft.com/interop/cp/default.mspx). this is from QA section: Q: Is this Community Promise legally binding on Microsoft and will it be available in the future to me and to others? A: Yes, the CP is legally binding upon Microsoft. The CP is a unilateral promise from Microsoft and in these circumstances unilateral promises may be enforced against the party making such a promise. Because the CP states that the promise is irrevocable, it may not be withdrawn by Microsoft. The CP is, and will be, available to everyone now and in the future for the specifications to which it applies. As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft’s implementation of the same Covered Specification. This type of “suspension” clause is common industry practice. So it looks like that Mono is better off than JVM and Java
- pluies 16y ago
  Maybe the Mono project is more nimble because of the very limited number of applications running on it? Especially compared to the JVM.
  - grav1tas 16y ago
    That or its creators aren't concerned with the applications running on it as much as the maintainers of the JVM are. Sometimes I think open source projects can have an advantage in this respect. If they're not financially bound to their customers when it comes to what the product actually does, they can focus more on their vision of the product is, and not what the customers/users whine and gripe about. Moreover if the users are whining and griping about some feature not being present or not well implemented, they can put forth the resources to implement it themselves...now I'm just repeating the FOSS talking points. Regardless, I think I agree that Mono is nimble because its user base is still relatively small or not large, but I think there are also other contributing factors.
sagarun 16y ago
This blog post sounds like telling the world that 'mono is not dead "yet" '
- YooLi 16y ago
  Did we read the same blog post?
jasonkester 16y ago
I just looked back into Mono to see what they've been up to in the last year, and it's nice to see that they're finally back on track: http://www.mono-project.com/Compatibility http://www.mono-project.com/Compatibility They've always had this annoying tendency to stray from the things we need them to be working on (getting a 100% feature complete version of the latest .NET CLR) and into things that are cool but not really core, such as the long list described in this post. I gave them a hard time about this a year ago, when they came up with a similar list of fun side projects yet still had major pieces of .NET 2.0 unfinished, such as this one that was stopping me from using them: https://bugzilla.novell.com/show_bug.cgi?id=346561 https://bugzilla.novell.com/show_bug.cgi?id=346561 Sounds like they have enough people on the core now that they're mostly up to date on 3.5 and starting on 4.0. That's great news (more-so than this blog entry, but it provides a nice excuse to give them some props).
srean 16y ago
This is great. Does this imply that Mono finally has constant stack space tail recursions ? Now I can look forward to (Iron)python without arbitrary restrictions on the depth of (tail)recursive calls. And no GIL too !
equark 16y ago
How does using .net affect acquisitions? Are the big firms like google, IBM, oracle, JVM only?

72 points by rayvega 16y ago

I poke in on Mono from time to time to see what's new there, and I probably don't do it enough. It seems like every time I show up they've finished what they were doing previously and a rolling into a host of other new things. These guys are freakin' rock stars at this stuff. In light of the fact that Java's future has a lot of people flummoxed, it might be interesting to see if there's increased entry into Mono. Are there any good general numbers on the type of use Mono is getting these days? I'd never expect to see some kind of mass exodus from Java or the JVM, but all these new language features and paradigms going into mono are just SO COOL. In the face of how long it took Java 7 to get rolling, Mono seems incredibly nimble to me, but at the same time it also doesn't have that rock solid feel that I get when I think about developing on the JVM. Mad props to these guys, the just never seem to get tired.

bad_user 16y ago
MonoDevelop gives me that feeling too, that's why when I did a small project with Mono I went to my trusted toolchain ... Emacs / Rake. Debugging is also painful; I'm still waiting for something like Python's debugger. On the other hand I trust that I'll get shit done with my favorite platforms (Python / Ruby / Linux) more than I trust Java, even though these are considered toys by other people, so it's a matter of personal preference / perspective.
nodata 16y ago
If Oracle can't be trusted with Java, can Microsoft be trusted with Mono?
- tomaszkubacki 16y ago
  Yes, since Microsoft Community Promise http://www.microsoft.com/interop/cp/default.mspx http://www.microsoft.com/interop/cp/default.mspx covers C# Language Specification
- bad_user 16y ago
  That's a silly question to ask because while these companies may look and sometimes behave the same, their relationships with the community are different. Just as in real-life, the best way to tackle this is to: a) when trust is involved, and you got screwed, the first thing you do is to end any relationship you have with that person / company and tell your friends about it. This sends a clear message which forces other people / companies to reassess their values (i.e. what's more important for your neighbor: you or your parking spot) If Oracle were to lose customers on this, I'd bet they would think twice before ditching ASF / Harmony. b) for people / companies that cannot be trusted, deals are sealed with contracts that are legally binding. In the case of SUN/Oracle: Apache warned everyone about the inability to implement a third-party open-source Java and OpenJDK was just a distraction from the real issue, which shows just how gullible we are (yeah, software developers never read the fineprint). In the case of C#/.NET ... at least the language, the core library and the CLR are real ECMA / ISO standards, there's also a patents grant that doesn't prevent supersets, and there is no TCK or fields-of-use restrictions to speak of. Some people say that these standards do not include important pieces of infrastructure like ASP.NET, WPF or Windows Forms: I say that's a feature, because you wouldn't want to carry that bloat to whatever platform you're targeting (like mobile phones). Just imagine MFC being part of the C++ specifications.
  - gnufreex 16y ago
    Apache != open source Apache wants Java under ASL, Oracle/sun don't want competitors forking their code and making proprietary. That's why Sun chose GPL. No fine-print, just GPL. You can make 3rd party implementation based on OpenJDK and get TCK. Red Hat did it with Iced Tea.
    - bad_user 16y ago
      Oracle/sun don't want competitors forking their code and making proprietary. That's why Sun chose GPL. That's the biggest bullshit I ever heard. And no, you can't make 3rd party implementations based on OpenJDK: the European Commission, when investigating the issue of MySQL being sold to Oracle, concluded that derivate works from GPL v2 licensed code are not protected from patents. That's because the "implicit" patents grant in GPL version 2, while it may hold in the US, it wasn't properly tested in court, and it is too weak for the European Union. Actually this loophole is the "raison d'etre" for GPL ver.3 (the other issues, like tivoization, appeared later). If SUN would have chosen the Apache License or GPL ver 3 (which was already available at that time) this wouldn't have been an issue. Thank you for proving my point ;)
- tzs 16y ago
  Generally yes. Mono can be split into three parts. First, there are the parts that implement the ISO/EMCA standards for C#, the runtime, and the libraries. Second, there are additional libraries that are in .NET for doing various non-portable things on Windows (like writing Windows GUIs), for which Mono has made compatible libraries for non-Windows. Third, there are additional non-Windows things Mono has added. Some of these are new language features from versions of .NET that haven't yet went through ISO/ECMA. Others are things that Mono has added that don't have anything corresponding in .NET. For items in the first part, Microsoft had to make any IP of theirs known to be necessary to implement the standard available on reasonable terms. The terms they used are the Microsoft Community Promise. For items in the second part, there may be some risk. The simplest thing to do is avoid those parts. For example if you want to write a program that needs to be portable to Windows, Mac, and Linux then instead of using the Windows-specific GUI stuff and Mono's compatible versions of those, use Mono's GTK#. That works on Windows. If you aren't trying to write a portable program, then there is even less reason to consider the Windows-specific stuff and its Mono equivalents. For items in the third part the risk seems low. Mono isn't using Microsoft code for the most part (and any Microsoft code they are using was released by Microsoft under the Apache 2 license which includes a strong IP grant), so copyright isn't going to be a problem. The potential problem would be patents. However most of the things in the third part are things that are also done in many other languages/runtimes and so any patents on the .NET versions are likely covering specific implementation details. There's no particular reason to believe that Mono's independent implementation would have used the same methods. In other words, for these things the risk that Microsoft would go after Mono is about the same as the risk that Microsoft would go after Java, or Perl, or Ruby, or Python for how those languages and runtimes do similar things. Actually, that's not quite right--the risk is probably lower, because Microsoft has provided encouragement for Mono. That's going to raise some estoppel arguments. They'd have less of a problem going after some other language where they might not have as many estoppel issues to deal with. Really, though, the big difference between Microsoft and Oracle here is attitude. Microsoft had encouraged independent and open source work on .NET. They've released quite a bit of their code under the Apache 2 license, including the .NET Micro Framework. The Apache 2 license has a strong patent grant. Sun/Oracle on the other hand have been reluctant to allow truly independent implementations of Java. They will not place the spec under control of a standards body. You can't get a patent license for an independent implementation unless you pass the TCK, and you can't get a license to the TCK under acceptable open source terms. Sun did release OpenJDK, but it is GPLv2. No explicit patent grant. There is probably an implicit patent grant but no one knows what the boundaries are, so the practical effect is that OpenJDK is likely to just track closely Oracle Java. I doubt you'll see any major effort to fork OpenJDK and add Java ME support for instance. A good illustration of the attitude difference can be seen with F#. The F# compiler did not initially work under Mono. Microsoft could have ignored that, opting to keep F# as a reason to encourage people to go with Windows and Microsoft's developer tools, and leave it to the Mono people to enhance Mono to be able to handle F#. Instead, Microsoft quickly updated F# to make the compiler work on Mono. If some Oracle thing didn't work on a non-Oracle JVM, I would be surprised if Oracle would leap in to make it work unless some big customer with a lot of money wanted it.
- Stasyan 16y ago
  But Microsoft is not in charge of Mono, plus Microsoft is applying Community Promise to Mono (http://www.microsoft.com/interop/cp/default.mspx http://www.microsoft.com/interop/cp/default.mspx). this is from QA section: Q: Is this Community Promise legally binding on Microsoft and will it be available in the future to me and to others? A: Yes, the CP is legally binding upon Microsoft. The CP is a unilateral promise from Microsoft and in these circumstances unilateral promises may be enforced against the party making such a promise. Because the CP states that the promise is irrevocable, it may not be withdrawn by Microsoft. The CP is, and will be, available to everyone now and in the future for the specifications to which it applies. As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft’s implementation of the same Covered Specification. This type of “suspension” clause is common industry practice. So it looks like that Mono is better off than JVM and Java
pluies 16y ago
Maybe the Mono project is more nimble because of the very limited number of applications running on it? Especially compared to the JVM.
- grav1tas 16y ago
  That or its creators aren't concerned with the applications running on it as much as the maintainers of the JVM are. Sometimes I think open source projects can have an advantage in this respect. If they're not financially bound to their customers when it comes to what the product actually does, they can focus more on their vision of the product is, and not what the customers/users whine and gripe about. Moreover if the users are whining and griping about some feature not being present or not well implemented, they can put forth the resources to implement it themselves...now I'm just repeating the FOSS talking points. Regardless, I think I agree that Mono is nimble because its user base is still relatively small or not large, but I think there are also other contributing factors.

sagarun 16y ago

This blog post sounds like telling the world that 'mono is not dead "yet" '

YooLi 16y ago
Did we read the same blog post?

jasonkester 16y ago

I just looked back into Mono to see what they've been up to in the last year, and it's nice to see that they're finally back on track: http://www.mono-project.com/Compatibility http://www.mono-project.com/Compatibility They've always had this annoying tendency to stray from the things we need them to be working on (getting a 100% feature complete version of the latest .NET CLR) and into things that are cool but not really core, such as the long list described in this post. I gave them a hard time about this a year ago, when they came up with a similar list of fun side projects yet still had major pieces of .NET 2.0 unfinished, such as this one that was stopping me from using them: https://bugzilla.novell.com/show_bug.cgi?id=346561 https://bugzilla.novell.com/show_bug.cgi?id=346561 Sounds like they have enough people on the core now that they're mostly up to date on 3.5 and starting on 4.0. That's great news (more-so than this blog entry, but it provides a nice excuse to give them some props).

srean 16y ago

This is great. Does this imply that Mono finally has constant stack space tail recursions ? Now I can look forward to (Iron)python without arbitrary restrictions on the depth of (tail)recursive calls. And no GIL too !

equark 16y ago

How does using .net affect acquisitions? Are the big firms like google, IBM, oracle, JVM only?