I don't think your feelings about Windows Server contradict my point: Microsoft is moving into a software-as-a-service model. It shouldn't be surprising that you want to ditch the old model. In many ways, it doesn't matter if you don't use Microsoft handheld devices; if you do things on the Internet, you almost certainly use their cloud services. And if anything can be learned from Apple's example, it's that rapid innovation can happen when you have the capability to vertically integrate. There are really only three players out there right now that can do that: Apple, Google, and Microsoft. I think it would be silly to call any one of those companies irrelevant.
I think your criticism against lock-in is fair, and this is clearly one of Microsoft's strategies, and I suspect that it will continue to be to some degree. But on the language front, you are wrong. Not only are Microsoft's newest languages open-source (F#, TypeScript), but they are also cross-platform and collaboratively developed with open source groups. And, of course, you can run all
While it is theoretically possible that all of this is a deadly Microsoft-bait-and-switch just waiting to happen, having worked at Microsoft, I can say that doing so would fly in the face of a lot of hard work by many, many people there. I was as critical about Microsoft as you were (dig into my
Microsoft is a big company (the Redmond campus is mind-bogglingly huge to me) and they have a lot of corporate momentum. Despite this, in my opinion, I've seen my daily interactions with people do a complete 180 in the last couple of years. Microsoft knows that the era of selling boxed copies of proprietary software is coming to an end. So you're simply wrong about Microsoft not being able to change.
Whatever algorithm Google is using to do this, I think its details are in the public interest. I'd like to see them publish its details.
On the other hand, many properties about programs themselves can and should be verified. A great deal of current programming language research is devoted toward both improving the capabilities of automatic program verification as well as designing languages more amenable to verification. Functional languages, for instance, rule out entire classes of bugs present in imperative languages. People complain that they're hard to understand. Maybe. I argue that they're hard to understand if you're the kind of person who does not care about whether your program is correct or not.
Unless and until some unforeseen, miraculous breakthrough happens in language design, GCd languages will always be slower when it comes to memory management. And because memory management is so critical for complex applications, GCd languages will effectively always be slower, period.
This isn't true. Have a look at Quantifying the Performance of Garbage Collection vs. Explicit Memory Management. The take-away is that GC'd languages are only slower if you are unwilling to pay an extra memory cost; typically 3-4x of your explicitly-managed program. Given that GC gives you safety from null-pointer dereferences for free, I think that's a fair tradeoff for most applications (BTW, you can run the Boehm collector on explicitly-managed code to identify pointer safety issues).
When you're done with that, go read What Every Computer Scientist Should Know About Floating-Point Arithmetic. I cribbed the example directly from the article.
(0.1 + 0.2) == 0.3
It doesn't matter how many bits you use in floating point. It is always an approximation. And in base-2 floating point, the above will never be true.