Maybe so you can make a crossplatform program? Portability is an advantage, really. Linux is unlikely to always be the best platform for you
Linux won't be "the best platform" as long as everything that runs on it is cross-platform stuff. Linux needs a native toolkit, one that wastes no time or effort on cross-platform features. Qt will always be hamstrung by Troll Tech's commercial interests in shipping a cross-platform toolkit.
And if your program would be GPL anyway it's not an encumberance.
But it wouldn't be. I have written lots of different software under lots of different licenses. A toolkit that forces me to make everything either GPL or proprietary is a non-starter.
Remember Qt is not only C++ but actually pushes that to the extent that it needs a separate preprocessor.
A toolkit (such as GTK) being LGPL:d means that a company can make a comemrcial app _without_ giving back nothing to the community!
Companies that want to develop commercial apps without giving back to the community already can: there are plenty of GUI toolkits with BSD and X11 licenses for Linux. Furthermore, GUI toolkits on commercial platforms (Windows, OS X) are included with the OS. In order to compete, the standard Linux GUI toolkit should have a license that allows proprietary software to be developed with it. Note that I'm not saying all libraries should--this is a decision one needs to make on a case-by-case basis.
Their next step would be to advertise the hell out of their competition.
That would be wonderful: if they advertise that Linux is a good platform for their application, we all benefit.
MS...
Is MS shipping Gtk+-based applications on Linux? I think that would be great--we couldn't ask for better PR.
This is the largest load of crap I've heard in a long time, especially directed to someone who's a student.
The guy took a C++ class; he is now writing games (presumably for fun or for a living). So, this is not a "student" question, it's a "how do I get this done in the real world" kind of question.
as opposed to being a reactionary turd who'll refuse to better himself.
Well, at least he isn't someone who automatically follows every new fad. Global variables are still useful and reasonable, as is saving them by saving a chunk of memory. It's a simple, effective, time-tested technique. It has some (known) limitations, but if he can live with those, it may be the right technique for him.
But he wants to know if there's a better way.
And the answer is: there isn't a uniformly "better" way. There are different ways of solving this problem that involve different tradeoffs.
Don't change something just because someone tells you it's not the latest and greatest way of doing things. If saving the way you do works for you, just stick with it. It has a number of potential problems (portability, maintainability, version and architecture dependence), but if those don't bother you right now, there is no need to change until they do.
I made a point about languages: Microsoft has demonstrated that C# can be compiled into code comparable to C, C++, and Java, even for compute-intensive inner loops. For Python, Perl, and PHP, nobody has been able to do that.
When Mono will catch up, I don't know. They were already pretty close last year, and this is high on their agenda, so I expect it won't be long. In any case, even Mono is a lot more efficient for compute-intensive loops than Python, Perl, or PHP.
They may be similar in terms of what they can actually do, but with Qt you can do it a lot easier.
I don't find that to be the case. While using Gtk+ in raw C is kind of cumbersome, Gtk+ has excellent C++, C#, and Python bindings.
And Qt has many things not included in GTK, like networking and multithreading bits.
That's because Qt is a cross-platform library, while Gtk+ is a GUI toolkit. Why would I want to have a license-encumbered C++ wrapper around the native Linux APIs?
You are asking a different question. Of course, there are developers who license Qt, just for the Windows and cross-platform support alone; doing so comes with the usual problems that licensing an expensive library from a little company has. If you want to compare apples to apples, you have to ask how many commercial Linux-only apps there are in Qt vs. Gtk+. I don't know of any for either toolkit.
The point I was making that Qt is unattractive for building into open source platforms. That's why Sun's desktop is based on Gnome, not KDE, and it's why Mono, SWT, and wxWindows use Gtk+ and not Qt.
Qt licenses are a small price for any large corp., next to overall dev costs. Somehow, I don't think you've done much real-life development. If I'm wrong, sorry.
Somehow I think you haven't worked in a large corporation recently. Qt licenses may be a small price relative to other costs, but those are different budgets. Software license budgets are tiny, and it is generally assumed that everything you need either falls under the corporate-wide Microsoft license, or you can get it open source.
Finally, Qt is GPL'd. That means it's protected from proprietary ravages, unlike, say, ASP.NET. So no, it's not a marketing gimmick; grow up.
When I develop commercial software, I am not using the GPL'ed version, I'm using the commercial version. The fact that someone can fork and fix the GPL version does me no good because I can't use the GPL version or any contributions to it: I'm still at the complete mercy of Troll Tech.
So, yes, from the point of view of a commercial developer, the GPL version is a gimmick. Troll Tech is just another little company shipping an expensive library, and if they screw up, I'd be in deep trouble with my commercial product based on it. There are plenty of open source toolkits with commercial-friendly licenses, and they work well enough for most people, so there is no need to subject oneself to that kind of pain and risk.
Eclipse has to use non-standard native libraries to work as well as it does across platforms. Eclipse is, if anything, a testament to the failure of Sun's approach.
You have the typical Java blinders on. You think it's all about targeting all platforms.
I don't care. I want better tools for developing for Linux, and Mono gives me that. The fact that I also get two choices for deploying on Windows (Gtk# for Win32 and Windows.Forms) is icing on the cake. Mono gives me choices, Java gives me a straightjacket.
Java has already proven itself to be incapable of delivering high quality applications on any platform. If I really want to develop cross-platform applications, I use tools that work, i.e., not Java, but one of the mature C/C++ cross-platform toolkits.
Mono's goal, indeed its reason for being, is to clone Dotnet.
That's the reason Novell is paying the bill, and it is one goal among several.
Now suddenly (that is, since about October last year)
There is nothing "sudden" about it; the Gtk# bindings were there from pretty much the start of the Mono project, long before Windows.Forms was even usable. Almost all Mono GUI apps are written with them.
I'm sorry you weren't paying attention (or is it that you just make up false "facts" to badmouth projects you don't like).
For such projects the "draconian" (complete) compatibility of Java is an absolute requirement, and one which literally hundreds of thousands of developers rely on every day.
In my experience as a Java developer, Java achieves only limited compatibility across platforms. Even that is only because all implementations right now are derived from Sun-licensed code. In different words, Sun's pitch is the same as Microsoft's: license all your software from one source and all your compatibility worries will go away. Thanks, but I don't want a Sun monopoly any more than a Microsoft monopoly.
To people developing platforms that may be used by commercial developers. That's, for example, why Sun chose Gnome rather than KDE and it's also why Mono chose Gtk+.
Large commercial corporations? Frankly, the cost of a Qt licence is minimal for a 100% Qt developer
Frankly, you are full of shit. I have worked at "large commercial corporations", and the Qt licenses are a lot of money in today's corporate environment, in particular considering that for a fraction of the cost, people can get VisualStudio.NET.
But the biggest problem is one of control: as a commercial developer, I have the same problem with Qt as I have with any other piece of proprietary software: Qt is under the control of one company. If they decide to do things with it that cause problems for me (jack up prices, change strategies), I have no alternative or choice. The Qt library has the same risk as any other proprietary software product from some small company; the fact that it also has a GPL version is a marketing gimmick.
You're missing the point. The book advances a hypothesis, a hypothesis that is worth considering. Part of the support for that hypothesis is statistical data, which was poorly collected, not reproducible, and may have even involved selective counting by the author (most of the book apparently deals with historical arguments, not statistics).
This may come as news to you, but the same can be said for probably the majority of academic publications. People don't get fired over it in droves (universities would be empty), they either get ignored or rebutted. In this case, the hypothesis is important enough that a careful rebuttal and data collection by people who don't believe in it would have been warranted; that's the way science progresses.
But because this guy crossed a politically powerful lobby, instead of sparking a wealth of research showing his hypothesis to be false, he simply got fired.
In fact, that leads to the question: where is the carefully collected data supporting the mainstream/gun-lobby view?
Those are nice languages, and I use them myself, but they are not alternatives to C#, for many reasons. For example, they lack static type checking and they don't compile into code that is comparable to compiled C/C++ in terms of performance.
The use of the term.NET with Mono is problematic. Mono implements large parts of.NET, but it also has its own set of APIs. By linking Mono so closely to the.NET name, the project reinforces the notion that they are completely subject to Microsoft's legal and platform strategy with respect to.NET. But the fact is that.NET and.NET compatibility in Mono could disappear tomorrow and Mono would still be a great and enormously useful project.
The Qt licensing issues haven't been resolved: it is still only available under the GPL or commercial licenses. That may be good enough for shipping the KDE desktop, but it is not acceptable if Linux is to be a major player for commercial applications.
The choice between Qt and Gtk+ is pretty easy: functionally, they are similar, but Gtk+ is LGPL. Therefore people can develop commercial apps with Gtk+ without paying anyone, and if you are creating a platform that you hope will attract Windows developers, that matters.
In the long run, it doesn't really matter what they pick now, since both Gtk+/Gnome and Qt/KDE are obsolete. Mono will likely get a nice, managed toolkit that evolves out of its Gnome bindings.
Meanwhile, Sun has legally committed themselves to allowing FOSS implementations of the Java spec. This includes licensing agreements for any relevant patents that would hinder a standard FOSS implementation.
Sun has not "legally committed" to allowing FOSS implementations of the Java spec, they haver merely stated their intention, something with no legal significance. Even if they had legally committed, Sun's compatibility requirements make it practically impossible to create FOSS implementations.
Sun is trying to lure the FOSS community into a legal trap with Java. At this point, it's pretty clear that this is not Sun screwing up anymore, it's a deliberate strategy. Java is not only legally encumbered, it's also owned by a company that has demonstrated that it can't be trusted.
I don't care whether you use C#, but whatever you do, if you care one bit about the ability to create FOSS, do not use Java.
Perhaps you should read your own link. Only C# and CLI are ECMA approved standard. The other 80% of.Net (aprox.) is Microsoft property.
And perhaps you should read a bit more about Mono: Mono comes with two sets of APIs.
One set is a reimplementation of.NET: it's where Novell sees money coming in, and it's there for people to port applications from Windows to Linux. But it's not what most Mono developers are going to be developing in.
The other set is a binding of C# to existing Linux open source tools (Gtk+, Gnome, etc.). That's the set that most open source developers are going to be using. It doesn't rely on.NET and gets by with ECMA C#.
Until M$ comes out with an open source license for.NET, Miguel and the Mono guys are walking on really thin ice.
M$ has come out with an open source license for ECMA C#. That's all Mono really needs because it has its own set of APIs in place of.NET.
The.NET compatibility in Mono really is skating on thin ice, but that is an intrinsic problem with providing compatibility with anything from Microsoft. If.NET compatibility were to become legally impossible for Mono tomorrow, it would not be such a big deal for most Mono users and developers because they aren't relying on it (although it might be a problem for Novell's business strategy).
For myselft, years back I started dabbling in C# thinking I'd broaden my programming knowledge. But I have to say that I prefer Java over C#
Well, if you have any legal concerns about.NET, then Java should send chills down your spine: Java is completely owned and controlled by Sun, not only through patents, but also through license agreements on everything related to Java.
C# is just too Microsoft and there's something about the feel of it that gives me goosebumps. Like my old, really old, yukky VB days.
I don't like the method names and Microsoft case either, but those little things will make it easier to attract Microsoft developers to Linux. And that's a good thing.
However, count me among those who prefer JNI to P/Invoke and unsafe code. Why would I want to pollute my java/c# codebase with c code? I prefer putting this code in a seperate library and using p/invoke or jni
By letting you express unsafe code in C#, you can do things efficiently that are impossible to do efficiently in JNI.
Furthermore, using unsafe code in C# makes the code platform and processor independent and makes it far easier to deploy than JNI native libraries.
Finally, P/Invoke makes it easy to bind to existing native libraries without having to write native wrappers for it; again, it simplifies deployment and access to legacy code.
The real nuts-and-bolts of.NET are decidedly NOT an open standard. This is what concers many people.
Yes, large parts of.NET are not an open standard. But it's wrong to refer to those as "the real nuts-and-bolts", which falsely suggests that Microsoft kept important portions of the low-level foundations of C# proprietary.
ECMA C# is a complete and powerful language and set of libraries--far more complete than C or C++. Together with the open source APIs that already exist on Linux (Gtk, Gnome, etc.), it gives you a fully open and documented platform to build applications on.
Additionally, since.NET is a wholly controlled "standard" by MS then Mono will be on the same treadmill that WINE and other groups chasing MS implementations have been on.
Most open source Mono developers won't be affected by.NET at all because they won't be using.NET; they'll be using C# with open source APIs.
If you choose to use.NET, for example because you are developing a Windows application that you also make available on Linux, then, of course, you are dependent on the.NET APIs, but that's because you chose to use.NET. Mono is doing the best job they can in giving you that capability, but even if they fail, it just won't make a difference to open source developers.
Also note that Mono is in a far better situation in this regard than open source Java efforts: Sun has draconian compatibility requirements with which they may be able to shut down any open source Java project whenever they choose.
Slashdot Mirror
Maybe so you can make a crossplatform program? Portability is an advantage, really. Linux is unlikely to always be the best platform for you
Linux won't be "the best platform" as long as everything that runs on it is cross-platform stuff. Linux needs a native toolkit, one that wastes no time or effort on cross-platform features. Qt will always be hamstrung by Troll Tech's commercial interests in shipping a cross-platform toolkit.
And if your program would be GPL anyway it's not an encumberance.
But it wouldn't be. I have written lots of different software under lots of different licenses. A toolkit that forces me to make everything either GPL or proprietary is a non-starter.
Remember Qt is not only C++ but actually pushes that to the extent that it needs a separate preprocessor.
Yes, that alone is a good reason not to use it.
A toolkit (such as GTK) being LGPL:d means that a company can make a comemrcial app _without_ giving back nothing to the community!
Companies that want to develop commercial apps without giving back to the community already can: there are plenty of GUI toolkits with BSD and X11 licenses for Linux. Furthermore, GUI toolkits on commercial platforms (Windows, OS X) are included with the OS. In order to compete, the standard Linux GUI toolkit should have a license that allows proprietary software to be developed with it. Note that I'm not saying all libraries should--this is a decision one needs to make on a case-by-case basis.
Their next step would be to advertise the hell out of their competition.
That would be wonderful: if they advertise that Linux is a good platform for their application, we all benefit.
MS...
Is MS shipping Gtk+-based applications on Linux? I think that would be great--we couldn't ask for better PR.
This is the largest load of crap I've heard in a long time, especially directed to someone who's a student.
The guy took a C++ class; he is now writing games (presumably for fun or for a living). So, this is not a "student" question, it's a "how do I get this done in the real world" kind of question.
as opposed to being a reactionary turd who'll refuse to better himself.
Well, at least he isn't someone who automatically follows every new fad. Global variables are still useful and reasonable, as is saving them by saving a chunk of memory. It's a simple, effective, time-tested technique. It has some (known) limitations, but if he can live with those, it may be the right technique for him.
But he wants to know if there's a better way.
And the answer is: there isn't a uniformly "better" way. There are different ways of solving this problem that involve different tradeoffs.
Don't change something just because someone tells you it's not the latest and greatest way of doing things. If saving the way you do works for you, just stick with it. It has a number of potential problems (portability, maintainability, version and architecture dependence), but if those don't bother you right now, there is no need to change until they do.
I made a point about languages: Microsoft has demonstrated that C# can be compiled into code comparable to C, C++, and Java, even for compute-intensive inner loops. For Python, Perl, and PHP, nobody has been able to do that.
When Mono will catch up, I don't know. They were already pretty close last year, and this is high on their agenda, so I expect it won't be long. In any case, even Mono is a lot more efficient for compute-intensive loops than Python, Perl, or PHP.
They may be similar in terms of what they can actually do, but with Qt you can do it a lot easier.
I don't find that to be the case. While using Gtk+ in raw C is kind of cumbersome, Gtk+ has excellent C++, C#, and Python bindings.
And Qt has many things not included in GTK, like networking and multithreading bits.
That's because Qt is a cross-platform library, while Gtk+ is a GUI toolkit. Why would I want to have a license-encumbered C++ wrapper around the native Linux APIs?
You are asking a different question. Of course, there are developers who license Qt, just for the Windows and cross-platform support alone; doing so comes with the usual problems that licensing an expensive library from a little company has. If you want to compare apples to apples, you have to ask how many commercial Linux-only apps there are in Qt vs. Gtk+. I don't know of any for either toolkit.
The point I was making that Qt is unattractive for building into open source platforms. That's why Sun's desktop is based on Gnome, not KDE, and it's why Mono, SWT, and wxWindows use Gtk+ and not Qt.
No one uses GTK+ for anything except Gnome.
Sun and Eclipse do, for example.
Qt licenses are a small price for any large corp., next to overall dev costs. Somehow, I don't think you've done much real-life development. If I'm wrong, sorry.
Somehow I think you haven't worked in a large corporation recently. Qt licenses may be a small price relative to other costs, but those are different budgets. Software license budgets are tiny, and it is generally assumed that everything you need either falls under the corporate-wide Microsoft license, or you can get it open source.
Finally, Qt is GPL'd. That means it's protected from proprietary ravages, unlike, say, ASP.NET. So no, it's not a marketing gimmick; grow up.
When I develop commercial software, I am not using the GPL'ed version, I'm using the commercial version. The fact that someone can fork and fix the GPL version does me no good because I can't use the GPL version or any contributions to it: I'm still at the complete mercy of Troll Tech.
So, yes, from the point of view of a commercial developer, the GPL version is a gimmick. Troll Tech is just another little company shipping an expensive library, and if they screw up, I'd be in deep trouble with my commercial product based on it. There are plenty of open source toolkits with commercial-friendly licenses, and they work well enough for most people, so there is no need to subject oneself to that kind of pain and risk.
Eclipse has to use non-standard native libraries to work as well as it does across platforms. Eclipse is, if anything, a testament to the failure of Sun's approach.
Here is another analysis, and a comparison with a pro-gun academic who fabricated data...
You have the typical Java blinders on. You think it's all about targeting all platforms.
I don't care. I want better tools for developing for Linux, and Mono gives me that. The fact that I also get two choices for deploying on Windows (Gtk# for Win32 and Windows.Forms) is icing on the cake. Mono gives me choices, Java gives me a straightjacket.
Java has already proven itself to be incapable of delivering high quality applications on any platform. If I really want to develop cross-platform applications, I use tools that work, i.e., not Java, but one of the mature C/C++ cross-platform toolkits.
Mono's goal, indeed its reason for being, is to clone Dotnet.
That's the reason Novell is paying the bill, and it is one goal among several.
Now suddenly (that is, since about October last year)
There is nothing "sudden" about it; the Gtk# bindings were there from pretty much the start of the Mono project, long before Windows.Forms was even usable. Almost all Mono GUI apps are written with them.
I'm sorry you weren't paying attention (or is it that you just make up false "facts" to badmouth projects you don't like).
For such projects the "draconian" (complete) compatibility of Java is an absolute requirement, and one which literally hundreds of thousands of developers rely on every day.
In my experience as a Java developer, Java achieves only limited compatibility across platforms. Even that is only because all implementations right now are derived from Sun-licensed code. In different words, Sun's pitch is the same as Microsoft's: license all your software from one source and all your compatibility worries will go away. Thanks, but I don't want a Sun monopoly any more than a Microsoft monopoly.
To whom?
To people developing platforms that may be used by commercial developers. That's, for example, why Sun chose Gnome rather than KDE and it's also why Mono chose Gtk+.
Large commercial corporations? Frankly, the cost of a Qt licence is minimal for a 100% Qt developer
Frankly, you are full of shit. I have worked at "large commercial corporations", and the Qt licenses are a lot of money in today's corporate environment, in particular considering that for a fraction of the cost, people can get VisualStudio.NET.
But the biggest problem is one of control: as a commercial developer, I have the same problem with Qt as I have with any other piece of proprietary software: Qt is under the control of one company. If they decide to do things with it that cause problems for me (jack up prices, change strategies), I have no alternative or choice. The Qt library has the same risk as any other proprietary software product from some small company; the fact that it also has a GPL version is a marketing gimmick.
You're missing the point. The book advances a hypothesis, a hypothesis that is worth considering. Part of the support for that hypothesis is statistical data, which was poorly collected, not reproducible, and may have even involved selective counting by the author (most of the book apparently deals with historical arguments, not statistics).
This may come as news to you, but the same can be said for probably the majority of academic publications. People don't get fired over it in droves (universities would be empty), they either get ignored or rebutted. In this case, the hypothesis is important enough that a careful rebuttal and data collection by people who don't believe in it would have been warranted; that's the way science progresses.
But because this guy crossed a politically powerful lobby, instead of sparking a wealth of research showing his hypothesis to be false, he simply got fired.
In fact, that leads to the question: where is the carefully collected data supporting the mainstream/gun-lobby view?
Those are nice languages, and I use them myself, but they are not alternatives to C#, for many reasons. For example, they lack static type checking and they don't compile into code that is comparable to compiled C/C++ in terms of performance.
The use of the term .NET with Mono is problematic. Mono implements large parts of .NET, but it also has its own set of APIs. By linking Mono so closely to the .NET name, the project reinforces the notion that they are completely subject to Microsoft's legal and platform strategy with respect to .NET. But the fact is that .NET and .NET compatibility in Mono could disappear tomorrow and Mono would still be a great and enormously useful project.
.Net is a fantastic language.
.NET is the language plus a large set of APIs.
The language is C#;
as soon as the Qt licensing issues were resolved
The Qt licensing issues haven't been resolved: it is still only available under the GPL or commercial licenses. That may be good enough for shipping the KDE desktop, but it is not acceptable if Linux is to be a major player for commercial applications.
The choice between Qt and Gtk+ is pretty easy: functionally, they are similar, but Gtk+ is LGPL. Therefore people can develop commercial apps with Gtk+ without paying anyone, and if you are creating a platform that you hope will attract Windows developers, that matters.
In the long run, it doesn't really matter what they pick now, since both Gtk+/Gnome and Qt/KDE are obsolete. Mono will likely get a nice, managed toolkit that evolves out of its Gnome bindings.
Meanwhile, Sun has legally committed themselves to allowing FOSS implementations of the Java spec. This includes licensing agreements for any relevant patents that would hinder a standard FOSS implementation.
Sun has not "legally committed" to allowing FOSS implementations of the Java spec, they haver merely stated their intention, something with no legal significance. Even if they had legally committed, Sun's compatibility requirements make it practically impossible to create FOSS implementations.
Sun is trying to lure the FOSS community into a legal trap with Java. At this point, it's pretty clear that this is not Sun screwing up anymore, it's a deliberate strategy. Java is not only legally encumbered, it's also owned by a company that has demonstrated that it can't be trusted.
I don't care whether you use C#, but whatever you do, if you care one bit about the ability to create FOSS, do not use Java.
Perhaps you should read your own link. Only C# and CLI are ECMA approved standard. The other 80% of .Net (aprox.) is Microsoft property.
.NET: it's where Novell sees money coming in, and it's there for people to port applications from Windows to Linux. But it's not what most Mono developers are going to be developing in.
.NET and gets by with ECMA C#.
And perhaps you should read a bit more about Mono: Mono comes with two sets of APIs.
One set is a reimplementation of
The other set is a binding of C# to existing Linux open source tools (Gtk+, Gnome, etc.). That's the set that most open source developers are going to be using. It doesn't rely on
Until M$ comes out with an open source license for .NET, Miguel and the Mono guys are walking on really thin ice.
.NET.
.NET compatibility in Mono really is skating on thin ice, but that is an intrinsic problem with providing compatibility with anything from Microsoft. If .NET compatibility were to become legally impossible for Mono tomorrow, it would not be such a big deal for most Mono users and developers because they aren't relying on it (although it might be a problem for Novell's business strategy).
.NET, then Java should send chills down your spine: Java is completely owned and controlled by Sun, not only through patents, but also through license agreements on everything related to Java.
M$ has come out with an open source license for ECMA C#. That's all Mono really needs because it has its own set of APIs in place of
The
For myselft, years back I started dabbling in C# thinking I'd broaden my programming knowledge. But I have to say that I prefer Java over C#
Well, if you have any legal concerns about
C# is just too Microsoft and there's something about the feel of it that gives me goosebumps. Like my old, really old, yukky VB days.
I don't like the method names and Microsoft case either, but those little things will make it easier to attract Microsoft developers to Linux. And that's a good thing.
However, count me among those who prefer JNI to P/Invoke and unsafe code. Why would I want to pollute my java/c# codebase with c code? I prefer putting this code in a seperate library and using p/invoke or jni
By letting you express unsafe code in C#, you can do things efficiently that are impossible to do efficiently in JNI.
Furthermore, using unsafe code in C# makes the code platform and processor independent and makes it far easier to deploy than JNI native libraries.
Finally, P/Invoke makes it easy to bind to existing native libraries without having to write native wrappers for it; again, it simplifies deployment and access to legacy code.
I agree with the points you listed. There are some more advantages of C# over Java, in addition to the ones you already mentioned:
* Multidimensional arrays
* Unsafe code is portable and written in C# itself
* Call-by-reference
The real nuts-and-bolts of .NET are decidedly NOT an open standard. This is what concers many people.
.NET are not an open standard. But it's wrong to refer to those as "the real nuts-and-bolts", which falsely suggests that Microsoft kept important portions of the low-level foundations of C# proprietary.
.NET is a wholly controlled "standard" by MS then Mono will be on the same treadmill that WINE and other groups chasing MS implementations have been on.
.NET at all because they won't be using .NET; they'll be using C# with open source APIs.
.NET, for example because you are developing a Windows application that you also make available on Linux, then, of course, you are dependent on the .NET APIs, but that's because you chose to use .NET. Mono is doing the best job they can in giving you that capability, but even if they fail, it just won't make a difference to open source developers.
Yes, large parts of
ECMA C# is a complete and powerful language and set of libraries--far more complete than C or C++. Together with the open source APIs that already exist on Linux (Gtk, Gnome, etc.), it gives you a fully open and documented platform to build applications on.
Additionally, since
Most open source Mono developers won't be affected by
If you choose to use
Also note that Mono is in a far better situation in this regard than open source Java efforts: Sun has draconian compatibility requirements with which they may be able to shut down any open source Java project whenever they choose.