Digging Deeper into the Visual Basic Lan

　　February 1st, 2017

　　Today Mads made an excellent post about our overall .NET Language Strategy. As I know this will raise a lot of questions in the VB community I wanted to take an entire post on the VB team blog to dive deeper into how VB fits into that strategy and why and what that means in practical terms for us as a community. Looking Back Six and half years ago, the Visual Studio Languages team laid out the motivations for our then-new co-evolution strategy. Mainly the significant overlap in adoption between VB and C# in adoption and use cases and four “powerful unifying forces” they shared:

　　The common IDE and platform building blocks that VB and C# share. The shared “multi-paradigm, object-oriented, imperative, strongly-typed, etc.” natures of the languages. The need for strong inter-language interoperability and the trend for the richest language innovation opportunities to be at the boundaries of APIs (e.g. Generics, LINQ, Async). Customer feedback on language tooling parity. What’s Changed???????????????????????????????????????????????????????????????????????????????????????????????????????? In 2010, the four “powerful unifying forces” laid out were the dominant forces acting on our two largest languages and they acted on them in roughly the same way. Those four forces are still relevant, though no longer the dominant drivers of growth and innovation for .NET, the languages, or the language communities. Since 2010 several new forces have become major players in our ecosystem and they influence our languages very differently. The first force is the pull on Microsoft (and .NET) to expand beyond what have been our traditional workloads—Windows desktop software and on premises server software—to new workloads such as Cloud and Mobile. This is no surprise. And you can see the impact of this in Azure, .NET Core, ASP.NET Core, .NET on Docker on Linux, and Xamarin. Now, I see this force interacting with businesses in two ways. A weak interaction to migrate existing solutions from on premises infrastructure to the Cloud and to bridge existing applications into mobile and a strong interaction to build entirely new services optimized for the cloud from the ground up. The latter aligns very strongly with F#, as it’s a functional-first programming language designed to be very attractive in this arena; and C#, which is designed to appeal to a broad audience of existing developers, especially curly-brace developers, who are already developing in these domains. Our challenge is to ensure C# is competitive for that audience both in the language and in the tooling. It’s not that VB couldn’t be used for those purposes but the people already doing these things aren’t demanding VB and the design philosophy of it doesn’t generally appeal to them. VB.NET was always designed to draw developers already targeting Windows to Visual Studio/.NET (including existing VB6 developers) and developers new to programming in general or for whom programming was a secondary skillset. The former—the weak interaction to migrate off on premises infrastructure or bridge into mobile—I believe, does have a lot potential with the VB community. To be clear, it’s not because VB is unique in this. In fact, we suspect that there is a sizable equivalent subset of the C# community for whom this scenario is equally valid. But, because of the growing diversity of the kinds of workloads that people use C# for (in part because of the diversity of other languages C# draws from) that group of developers is a much more representative subset of VB developers all up. The second force is the pull on .NET to expand beyond Microsoft. To non-Microsoft platforms, non-Microsoft tools, and to workloads beyond the enterprise. This started at .NETs inception with the Mono project and continues today. A clear demand exists for .NET (and yes, specifically C#) outside of Windows and outside of Visual Studio: Mono, SharpDevelop, Rider, ScriptCS, Unity for Gaming, Xamarin for mobile, OmniSharp/VSCode. There has always been a set of people who don’t work here who have a fierce hunger to bring the elegance of C# to places beyond Microsoft and Windows. The significance of that force has grown tremendously in recent years and the result of that influence is evident today. A sizable chunk of the C# user base, for example, is from Unity. Game development, and development on or for Mac OS X are—not surprisingly—outside of Visual Basic’s wheelhouse. The third force is the pull to embrace open source software, practices, and tools. This has been part of F#’s DNA forever and F# is leading the pack here. C# is ramping up here but has a great head start, again look at Mono. But also, because C# competes/attracts from languages and communities, like Java and C++, where a lot of this is already in their DNA. How long has C# been bringing Java open source tools to .NET (NHibernate, NUnit, etc.)? VB doesn’t have that in its DNA. It’s along for the ride in places like Roslyn but it’s a challenge to create that culture where there hasn’t been one before and where you can’t draw developers from communities where that culture exists. 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. Maybe I’ll call these the four “powerfuller entropic forces” because I’m a nerd. A worthwhile observation is that, contrary to how customers often think of the causal relationship between them, the investments we make aren’t the force pushing the languages in these new arenas. The arenas are the forces pulling on them and the investments are responses. It’s not “if you just pushed Visual Basic harder on Linux it would be a huge player there” but “Gee, they really want C# on Linux, let’s make it easier for them”. Moving Forward So, what about the unifying forces—the common IDE and platform, the shared language heritage, the need for strong inter-language interoperability, and customer feedback? Those are all still active, alive and well. VB and C# still share an IDE in Visual Studio for Windows, they still share the .NET platform, a lot of the same customers, and they’re still basically similar languages. The “powerful unifying forces” aren’t going anywhere anytime soon. But with regard to the cloud and mobile, development beyond Visual Studio on Windows and for non-Windows platforms, and bleeding edge technologies we are leading with C#. This is because the audience in those spaces is demanding it. We will not shy away from Visual Basic open source contributions because in the long term any open source VB community is better than none. However, the focus for VB will be where VB is already or likely to be successful, i.e. primarily on Microsoft technologies and for Windows with an emphasis on bringing modern capabilities to existing solutions, developers, enterprises, and scenarios (e.g. SQL Azure). We’ll look for opportunities to bring new first-time developers into the Microsoft ecosystem through reinforcing Visual Basic’s brand as an approachable, productive tool for learning programming and rapidly building the kinds of applications it’s traditionally been great at. This means: Same great tooling—We started this with Roslyn in VS2015 with improvements to the code editing experience, such as refactoring and analyzers, and improvements to debugging such as new Edit-and-Continue functionality and support for LINQ and lambda expressions in the Immediate and Watch windows. Since VS2015 RTM almost every refactoring we’ve released in quarterly updates has been available in both C# and Visual Basic. And in VS2017 the new Live Unit Testing feature works for both C# and Visual Basic. Since 2015 we’ve been working on a language-neutral analysis API to make library analyzers which target both Visual Basic and C# much easier. We’re moving all three languages to the new project system. And the adoption of the Roslyn workspaces platform by F# are enabling both the F# team and the community to light up many of the same great experiences all Visual Studio users have come to expect from their IDE regardless of language. Keeping in mind the huge number of Visual Basic developers that also use C# and vice versa we delivered an unprecedented cross-language refactoring and code navigation experience in VS2015. We will continue to make the experience of dual-wielding VB and C# an epic one. Same great platform—I continue to believe that .NET is the best thing to ever happen to Visual Basic, followed closely by Roslyn. Every time the platform has taken a leap, Visual Basic and C# have both jumped together (e.g. Generics, LINQ, Dynamic, and Async). Both languages were open sourced together, both compilers were made cross-platform together. In VS2017 Visual Basic will have full support for producing and consuming tuples and consuming ref-returning methods defined in referenced libraries. We want to make sure that VB continues to enjoy the benefits of the .NET platform, chief of which is a seamless interop on a common type system. It’s worth noting that F# did work here as well to ensure that it enjoys that same benefit. I would expect that as the design of Async streams and nullable-reference types stabilizes to see work in both VB and F# to take advantage of the new platform offerings. And we are working to ensure that Visual Basic can target .NET Standard to ensure your VB assets can continue to add value on .NET Core. Same great language—Visual Basic is a powerful fully-featured language. There will be new features in Visual Basic that make it more productive with each version. Because of their similarities often a productive feature added to one language has been adopted by the other at the same time, not because anyone made us or because they were tied to the platform but because they were awesome (e.g. String Interpolation, the ?. operator, and NameOf). And thanks to the open source community we’ve seen that true of F# as well where community contributors have added nameof and string interpolation. That will continue. But a feature that doesn’t add significant value to the VB customers and scenarios and isn’t central to the platform (e.g. UTF-8 strings) won’t be added to VB just because it’s added to C#. And I, as a language designer and compiler contributor, will be focusing my efforts on language improvements to double down on its approachability and productivity. Hopefully this gives some insight into what I believe this shift in strategy means for Visual Basic and, as importantly, what it doesn’t mean. RFC, Anthony D. Green Visual Basic Language Designer