Digging Deeper into the Visual Basic Language Strategy
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
Thank you for clarifying. I am equally skilled in VB and C# and I have always recommended all .Net developers be so. There really is no excuse not to be. That being said, the presentation given by Mads was terrible. It made VB sound like a second rate hack language not worthy of citizenship in Visual Studio. I know that is not the case. VB is an awesome language and I hope will remain a First Class Citizen in Visual Studio forever and ever. It serves a very important purpose. Giving VB develops the cold shoulder is not something MS should do. Show them some love and they will return in kind.
I much appreciate the excellent detailed explanation!
Nevertheless, the view that VB.Net would be used just for on-boarding older VB6 developers and introducing new/beginner developers to .Net is incomplete to say the least and misses an important point: most of those who came to appreciate Visual Basic are doing it for its ease of use. It gets the job done and moves out of the way so the “developer” can focus on other (often, higher-level) aspects of the problem at hand. there is a group of quite seasoned software developers that still prefer VB.Net (despite the adversities in recent years) as a very effective tool to glue components (sometimes from diverse languages).
For a couple of years now there is a 5th force: Python grows in popularity for a good reason – like Visual Basic, it was easy to use, especially for scientists, mathematicians etc, people who needed to code effectively and get back to their problem. Unfortunately, while the Python community kept building and evolving, Microsoft decided to put some brakes on Visual Basic.
As there are efforts (such as ML.Net) to build .Net libraries for ML and AI (as opposed to relying on Python) it might not be too late to position VB.Net as the “Python” for .Net. With the right incentives, that would attract more people from the above mentioned segment (scientifically inclined, not big fans of curly braces) and also mitigate the massive alienation of the current VB.Net users (many of whom are disappointed and consider switching to Python and Linux – because Python on Windows is not as complete).
Microsoft managed to port SQL Server to Linux Although I hear there wasn’t much demand for that, I do believe that is a great step in the right direction!
I wish Microsoft will consider investing more in VB.Net (maybe re-positioning it, as hinted above) and I am sure it’ll pay off.
First, let me say I like and appreciate Anthony Green. He was a great asset to the VB.Net community and it’s a great loss that he no longer works at Microsoft. That said, in reading this blog post I think he was “toeing” the party line and doing his best to “soften” the blow of having VB.Net relegated to a second class citizen in .Net. While he claims that what he calls the four “powerfuller entropic forces” are being driven primarily by “outside” forces that want to use C#, he apparently completely misses the powerful outside forces driving the growth of Python. That force has driven the growth of Python primarily for all the “new” web and mobile related workloads that he claims are the primary two forces driving Microsofts push of C# into those “new” workloads. I would contend that if VB.Net was also a viable option for those “new” workloads, many Python developers would switch due to the more complete and powerful capabilities of VB.Net, and many current VB.Net developers would choose to use VB.Net to provide solutions in those “new” workloads.
IMHO, it’s ignorant and abusive to encourage someone to start with VB.Net because it’s easy to learn and then learn and use C# because it’s more capable. The only place it’s “more capable” are the areas where Microsoft is eliminating VB.Net as an option.