Visual Basic is the odd man out in the new .NET

In a series of blog posts last week, Microsoft detailed fundamental changes to how it develops its .NET languages. It was good news for C# and F# developers, but while Microsoft put a positive spin on what the changes meant for Visual Basic, the long-term future of the venerable language seems less certain.

Microsoft’s Visual Basic has long been one of the world’s if not favorite, then certainly one of the most widely used languages, and it really put Microsoft at the center of the enterprise stage. From its first six iterations as a language for client-server application development to its rebirth as part of the .NET platform, Visual Basic has been the go-to tool for quick development of enterprise applications. That’s in part because of its massive library of user interface components, along with connectors to common databases and a component model that’s allowed third parties to build businesses on providing additional functionality.

The switch to .NET as the foundation for Microsoft’s development strategy made sense for new languages like C#, but it meant changes to Visual Basic wherein code couldn’t easily migrate from the old Visual Basic to the new VB.NET.

It was a challenging transition for developers, and Visual Basic began to lose mind share inside enterprise development—and inside Microsoft. Even so, Microsoft promised to keep C# and VB.NET in sync. Features created for C# would become part of Visual Basic, the two languages developing together. The reason was that they were often used for the same task and had the same underlying nature: both strongly typed, object-oriented languages working with the same tools.

Visual Basic and C#: A new divergence is coming

With last week’s announcement, that co-evolution is gone. Microsoft will let the two languages go different ways, starting with the soon-to-be-released Visual Basic 15.

It’s not a surprising divorce. C#’s popularity has grown by leaps and bounds, while Visual Basic has slowly slipped down the charts, almost disappearing from the radar of popular programming query sites like Stack Overflow. Use cases are changing, too: Visual Basic is still focused on its original client-server paradigm, while C# has become a tool for n-tier web-based applications, working in the cloud and on premises. With more and more apps built to work with the web and the cloud, it’s not surprising that C# is becoming the first choice for many projects.

There are changes in how the languages are developed, too. C# has shifted to an open design model, which means its users are in the driver’s seat for prioritizing new features, thanks to an active mailing list and a public GitHub repository. Microsoft has already taken new features from outside the company—a big change from its traditional language engineering processes that focused on its research groups and internal product management teams.

Visual Basic also has an open design model, but it has different priorities from C#. It already supports a subset of C#’s features in its current builds as part of the release candidate of Visual Studio 2017.

As C# continues to diverge from Visual Basic, we’re going to see the two languages develop separately, though they should be able to work together. Both should still address the same .NET APIs, and both will still be part of the Visual Studio tools.

What these changes mean for enterprise developers

At the moment, there’s very little for enterprises to do about this coming divergence.

But in the future, there’s certainly scope for cross-platform work in Visual Basic, as it moves to supporting the .NET Standard set of base class libraries alongside the familiar .NET Framework. Although some code will be portable, not all Visual Basic code will be able to make the jump from one set of libraries to another smaller set. It’s likely that existing code will remain purely on Windows and purely in on-premises applications.

As a developer, you’re going to have to choose between bringing Visual Basic code to newer platforms via .NET Standard or moving to languages like C# that offer a wider range of target frameworks and devices.

Because .NET Standard is intended for all .NET platforms, it’s an important equalizer. However, it’s not necessary for all .NET languages. Although Visual Basic will need it on systems that don’t have the full .NET Framework, C# will be able to address platforms like .NET Core directly, accessing its APIs. That also makes it easier for C# derivatives, like Unity, to support their own specialized APIs.

C# with support for the .NET Framework on Windows and the open source .NET Core (running on Nano Server and in containers) will become the first choice for cloud and for mobile applications, while the F# functional programming model will be ideal for financial services and applications that rely on machine learning.

One clear driver for these changes is Microsoft’s Xamarin acquisition. Microsoft needs a cross-platform set of tooling to support a wider range of mobile devices, with Windows Mobile failing to gain enterprise market share as hoped. Even in Windows Mobile-friendly geographies like the United Kingdom, iOS and Android together have more than 80 percent of the market. Microsoft developers wanting to build mobile front ends for their applications will need to use tools like Xamarin to target the dominant mobile platforms.

With Xamarin focusing on C#, Microsoft must make it clear that C# is the first-class .NET language going forward. Although that’s not explicit in Microsoft’s recent language announcements, it’s strongly implied.

How you should manage your enterprise language strategy

This isn’t a good-bye to Visual Basic, but it is time to take stock of where you are and where you want to be. Existing Visual Basic applications can continue to be developed, but as the underlying .NET platform evolves, you should expect only a subset of .NET APIs to be available to your Visual Basic developers. Though that won’t likely be an issue in the short term, you should prepare for a longer-term migration to C# or F#, especially if you’re planning on either mobile or cross-platform user experiences for your applications.

It seems clear that the best option to avoid the overhang of technical debt is to make C# your priority for new development. C# has first-class support and a user-driven design model. It’s also the heart of Microsoft’s cross-platform development and its Universal Windows Platform. That means you can write business logic once, then deliver custom user experiences for the web, Windows 10, iOS, Android, and MacOS. There’s also enough language commonality that developers should be able to make the transitions relatively easily, picking up new features after initial training.