Unity is actually written in C and C++ as far as I am aware. Whether that is still true, I have no idea.
I never said .Net should be avoided.
I said I avoid it for reasons of cross-platform compatibility and legal considerations. In the end, what you or anyone else decides to use is entirely your concern. It's a judgment call.
I freely admit that I am not overly fond of it, but I have my reasons. I have spent considerable time with it, and have even found some bugs in Microsoft's version. You also have the fact that since the reference version is Windows only - it takes time for Mac and Linux to "catch up".
That might change, but at the moment, the reality is that a large portion of C# is simply not portable from Windows to other systems. C# was never designed or intended to be cross-platform. I do not recommend it for cross-platform work because of code maintenance.
Defacto languages make cross platform work harder. They often make syntax changes between major releases, and then depreciate support for the existing runtime - necessitating large and often unnecessary rewrites. Java is an example, and so is C# to a lesser degree. It makes the job of maintaining codebases that much more time-consuming and expensive. Standardized language compilers can generally support multiple standards. GCC for example can compile C90 code if you want it to.
That's good news, but given Microsoft's lack of enthusiasm for standards, I'll adopt a wait and see attitude. I do not expect much.
Yes and no. Now that APIs are considered intellectual property, the answer is probably not. I do not doubt Microsoft's good intentions, but I also do not doubt that they would use any means they can to absorb or remove a competitor -as Oracle tried to do when it tried to force Google to abandon its Java clone.
Sun had an informal arrangement, agreeing not to assert patents against Google because Google actually increased the use of Java - and thus its overall value. Sun seldom asserted patents because doing so is bad for business in the long run.
I disagree. Microsoft's installer architecture is independent of what is being installed. If they can't simply delete files and registry keys in the proper order, then that is a serious problem. One of Windows' long term problems that does not go away is the potential registry corruption. The Windows registry suffers from a design flaw known as "bit rot." Microsoft knows this - but has never taken decisive steps to alleviate the problem.
How many times have you had to manually delete keys or reinstall Windows because of it? I have lost count. Much of that and installer problems could be avoided if Microsoft redesigned the registry to be local to each user instead of system-wide.
Here is the way I see it. If you have a language like C#, where the reference standard does not separate what is core to the Framework and what is not, then how do you write portable code? You can't. It has gotten better , but it still stands to reason that C++ and C are clearly defined as to what is part of the language and what is not. They are designed to write portable code. C# is still trying to find its legs.
It is true that C and C++ do not define a GUI. Why should anyone - C# or C++? It's an unrealistic expectation. GUIs are not portable by nature because vendors cannot standardize on a single one. The closest anyone has ever come to a portable GUI would be window managers (usually written in C) on top of X11. The next closest effort are frameworks like Qt.
I strongly disagree with that statement. If you want to discuss it further on another thread, we can go over some examples. It is really off topic here. We have already wandered too far as is.
That again is a matter of design necessity. How much crap do you really need to cram into a "standard library" before it becomes redundant to the purpose of the language? C and C++ (debatable IMHO) were designed specifically so that the standards were minimum and that external libraries were easily linked for reusable code. It leads to fewer bugs in the language core.
Like it or not, in the real world, C and C++ libraries significantly outnumber and outclass (no pun intended) C# codebases. Linking C to C++ is a snap. Linking C# to anything other than .Net is a massive PITA - even if it is Microsoft's own COM based libraries in the Windows OS.
It is the number of contortions that you have to go through - plus the inherent insecurity of MSIL that have made some, including myself reject .Net for long term projects.