@GordonBGood: C++ is a widely used general purpose programming language that is at a level of maturity in C++11 that makes it more productive than you're giving it credit for. As Herb states, he and the standards folks need to put more emphasis on libraries, standard libraries for C++. Of course, this means they are, they will. A native BCL doesn't make much sense, but a set of portable, standard, efficient(of course, this is C++!) domain-specific libraries certainly does.
What is the C++ Renaissance in your opinion? How would you define it? I'm not sure it's the same as we, Microsoft, intended. Please elaborate.
I'll grant you everything you say in the first paragraph. C++11 indeed is much easier to use than any previous C++ standard, and from the Windows 8 Developer Preview and Visual Studio Developer Preview we can see that progress is being made on developing libraries to make it easier to do most of the things that one can already do very easily in equivalent generations of C# (or now VB).
As per Herb's talk here, Microsoft's view seems to be that the C++ is making a comeback or "Renaissance" in that it will become the programming language of choice for almost all applications programming due to the need for "more bang for the watt". At least some of his extrapolations are flawed, such as that mobile devices application programming is moving to C++; as I stated in a previous post, Apple has always been pro native language programming and of the other (two) major programming environment providers (other than Microsoft), C++ is at most a somewhat poorly supported secondary programming environment as compared to the "Coffee type" languages, meant more to be called through p/invoke (actually JNI) calls. Thus, there is no trend or movement to C++ there. As to use for server code, the point is likely well made that there is a requirement for the higher efficiency of C++ - other than that ASP.NET might still be desired as a more tightly controlled security model
Where there is a movement toward better native C++ support or a "C++ Renaissance" is within Microsoft itself, with native code C++ support in Visual Studio now making it feel like a first class language as compared to a distant cousin. This goes in hand with the support for WinRT, which of course is actually a native code implementation under the covers. With this movement, C++/CLI now feels like a distant cousin without much of a future as it is one of the languages without a formal connection to the new WinRT "Metro style" apps.
The view expressed in this video seems to be that higher and higher percentages of application programming will be done in native C++ over the next ten years due to this need for more "bang for the watt". I don't see that happening. As always, one will choose the appropriate language for the job. For faster development times where maximum performance isn't crucial, languages like C# (or even the quite low performance F#) will be chosen; where there are limitations in a VM environment, either a "pure" C++ development will be chosen or one will use a hybrid of VM languages calling more efficient C++ written libraries as required to overcome those limitations or for maximum performance. Nothing has changed, other than that C++, especially for Microsoft environments, has been made a little easier to use. If Microsoft really believed that most programming for the future needs to be done in C++, than those other languages would be de-emphasized with ways of porting existing code to native.
So that's my view: Thank you Microsoft for an improved C++(11) including conformance to the new standard(s) and libraries that support previously sorely lacking standards such as new asynchronous programming models and even advanced concepts such as AMP; however, even with all of this it isn't going to replace C# (and maybe VB) where programming productivity matters. As to other programming environments, one does what one must. I will likely (reluctantly) develop an Android app completely in C/C++ in order to overcome some limitations of the Android Java environment restricting memory use, but the majority of applications will continue to be written in Java in spite of the potential performance hit; for other applications such as games, C/C++ will be chosen for performance over Java. I would think that the same decisions would be made as for developing applications for Windows tablets or for a new version of Microsoft Phone (assuming it might support writing apps in native code), with a decision to use native C++ eased somewhat by the fact that Microsoft have provided a much easier to use and more powerful set of development tools for C++ for Microsoft products than as provided for Android's NDK.