From "Digging Deeper into the Visual Basic Language Strategy" by The Visual Basic Team blog:
...The fourth force is an accelerated development cycle. Shipping software quickly is hard. Shipping quality software quickly is harder. Shipping quality software quickly for two (or three) languages so that they all get there on the same day is insanely hard. Realizing the software you shipped quickly was perhaps shipped too quickly and was possibly not the right design two (or three) times and now all the samples have to be redone is just wasteful. And when you’re a team putting out a minimum viable product looking for feedback to drive rapid iteration it makes sense to target the largest and most diverse set of developers you can with the highest probability of using it early and providing valuable feedback. Based on numbers and past behavior that’s C#. This isn’t always the case, as technologies such as the Universal Windows Platform, Windows 8.x apps, and Roslyn were all released with both VB and C# support out of the gate. These technologies had very long development cycles that lent themselves to the kind of planning and execution coordination required to deliver both as the same time. But agile products are increasingly the norm at Microsoft (and beyond), and in most cases we will draft in C# and follow with Visual Basic based on telemetry and talking to customers to identify high value scenarios. ...
When I started professionally developing for .NET 1.0 in the year 2000, I could immediately see (as a seasoned Visual Basic developer since 1993) that C# was merely VB.NET hidden behind a C style language wrapper. This made great sense to me as a means for legacy C++ code (and legacy coders) to feel much more comfortable with (and encouraged to) port and rewrite old C++ MFC (and such) applications to .NET. But I knew that both languages were really VB, under the hood.
I mention this because, if we look as far as 20 years to the future, long after these surges in technologies for development of the 21st Century teens decade have matured, Visual Basic is the far superior language at embedding UML-quality code structure indications by way of the syntax of VB, in contrast to C#. This is no insult to C and the C legacy languages. Initially paper punch cards were used, long ago, and the most concise syntax, in terms of Chars needed to define code structure, was a real serious issue in terms of time consumption in just getting that code defined. The "logic per UNICODE character" efficiency of C# wins hugely over Visual Basic. But for well over 10 years, now we have IntelliSense, and that changes everything. I think the better UML-quality to all VB syntax is a great boon while coding, or when returning to review code written weeks earlier, and especially for peer review. FOR statement (i,t,i){} deciphering alone can cost lots for a peer trying to grasp another coder's work, when holding on to a truly archaic syntax of old C++ and Java, when we can do much better.
I believe VB.NET is the language of the future. It will no longer be the nineties and zeros in future decades, with worldwide software industries being beyond-full to the brim of C++ coders in need of assistance with their syntax impairment and addiction to obsolete editor syntax (as if IntelliSense didn't change everything in coding). The 21st century twenties decade might really surprise us at how superior VB is to work with and maintain, and I believe Microsoft should now start pushing VB again, especially since Xamarin is soon to support VB. That crosses the hump of needed maturity in Microsoft supporting technologies to free the VB coder from having to time-travel back to C syntax to leverage apps on various smart phones and such. Subroutine wins over silly VOID. I'm just teasing.
With all that discussed, I would be impressed to see the UWP documentation apply strong effort toward an eventual goal of each and every C# example code illustrated being accompanied by a Visual Basic version as well. C, C++, C#, and Java syntax need not shackle us all for decades ahead.
C++ unmanaged has an excuse: driver coding and tweaks akin to Assembly language. .NET managed means that C# has no such powers as C++ unmanaged, and thus has no excuse for the syntax impairment other than familiarity to old coders, and greater ease in porting an old C++ project into .NET and/or UWP. That has been, and maybe will remain to be for another 5-7 years (I am guessing), a major and important backward-compatibility with C++ syntax issue to even keep up with the onslaught of technology changes.
But I would not want to give up on Visual Basic as the superior syntax just to hold onto backward-compatibility with the syntax in old coders' (like me) brains much beyond the year 2025, or Microsoft is begging to be sideswiped by some new language developer creating a modern and super-readable, super-understandable syntax of keyword structure, for some other company, and making us Microsoft fans like me look bad.
Please get those VB code snippets going, please do realize that code maintenance is far superior when working with a superiorly illustrative syntax of keywords, and maybe even please check for yourself if rereading some code you've created, just as little as when 2 weeks stale and away from it, is a breeze in VB to recall the gist of it all, as compared to an ugly affair with C#.
Please also pass on the following text I quote from above, to any and all Microsoft personnel who have an interest in the classic battle between C++ and VB. (I used Visual Basic from version 1 through 6, and I fully know that VB pioneered so much of what Visual Studio can do today. When VS.NET was released in 2000, it was great to see Visual Basic take over all the new technologies and basically take charge of Visual Studio, fitting like a glove after VB6 usage.)
PLEASE PASS ON MY POWER-QUOTE:
...Visual Basic is the far superior language at embedding UML-quality code structure indications by way of the syntax of VB, in contrast to C#. This is no insult to C and the C legacy languages. Initially paper punch cards were used, long ago, and the most concise syntax, in terms of Chars needed to define code structure, was a real serious issue in terms of time consumption in just getting that code defined. The "logic per UNICODE character" efficiency of C# wins hugely over Visual Basic. But for well over 10 years, now we have IntelliSense, and that changes everything. I think the better UML-quality to all VB syntax is a great boon while coding, also when returning to review code written weeks earlier, and especially for peer review...
(Feel free to paraphrase or add your own wisdoms, if you forward or share this...)
Microsoft Windows: Life Without Walls