Open Letter on the Visual Basic Strategy 2023

[skurth]

Dear Microsoft,

I have been a professional developer since 2006 and have been working for the same company since then. Starting with C/C++ (MFC), the main application was later extended with .NET applications, which are still maintained today and have thousands of users. These .NET parts are mostly written in Visual Basic and are based on WinForms (together with third-party tools from DevExpress, probably the most stable duo ever created). In the meantime, various web services (WCF and ASP.NET) have also been developed.

In 2017, there was a small shock with the release from Microsoft that Visual Basic will not receive the same updates as C#. With various other releases (including support for Visual Basic and .NET 5+), the shock was eventually overcome. In the meantime, we have even written a .NET 5/6/7 web service in Visual Basic (although there is still no template available in Visual Studio for this purpose). The project has several libraries and hundreds of classes in them. The only thing missing were the opportunities with Entity Framework, which is why there is a project for this in C#.

Are extensions also changes?

First of all: We are happy that Visual Basic does not have all the same changes as C#. With certain extensions in C#, we wonder who needs this? Or what is it for when you can write something abbreviated and save 1 second of typing effort, but then need several minutes to understand the code again half a year later. In our opinion, this has little to do with professional programming, considering how often you have to take over, read, understand, and expand other programmers' code.
Back to the question: Are extensions also changes? We believe that extensions are not the same as changes. We don't want breaking changes to Visual Basic. We also don't need new spellings for existing features, such as a new Select statement. We don't need primary constructors either. No file access modifier. No abbreviations for string manipulations. No minimal APIs. The list could almost go on indefinitely, and many new C# features would be included in it.
What we miss are simple features or keywords that are not covered in the current version of Visual Basic. To be specific, these are the following points:

• Init Properties
• Required Properties
• Records
• Inline variable declarations

As you can see, it is a very manageable list. Other Visual Basic developers will have some additional points, but we believe we all agree on what Visual Basic stands for. In our opinion, this does not change the syntax, it simply extends it. And in a tolerable way for all Visual Basic programmers (from beginner to professional). Nobody is forced to use these things. It also does not make the language itself more complicated; it simply simplifies the lives of professional Visual Basic developers.

Our suggestions

We have different ideas on how Visual Basic could be continued in a reasonable framework.

• One idea would be for Microsoft to accept pull requests from the community for Visual Basic, with Microsoft continuing to lead.
• Another idea would be an annual survey by Microsoft among Visual Basic developers on which features from C# should be adopted in Visual Basic. The selection could already be filtered reasonably so that a few features can be selected at the end. A democratic process.
• Another idea would be for Microsoft to determine on its own which features (and no, none is not an option 😉) make sense in Visual Basic, taking into account all use cases and effort.

Microsoft also employs newer developers for whom such implementations would be excellent. They don't have to reinvent the wheel, but they have a certain template with C#. In addition, with "LangVersion" in the .vbproj file, everything is prepared to move forward with Visual Basic securely into the future.

A few words about Visual Studio

The specified strategy for Visual Basic in 2023 states:
We will continue to improve the Visual Studio experience for Visual Basic developers, such as providing analyzers, code fixes, and IDE productivity features.
That's great to hear, but in our opinion, it doesn't quite correspond to reality. For example, we miss IntelliCode (whole line completions). Also, and often opened as an issue (and closed every time), we miss a template for ASP.NET Core Webservice for Visual Basic. What has improved a lot lately (thanks!) are issues that concern refactoring or working in the IDE. There was a time when almost all issues regarding Visual Basic were directly closed, even if it didn't require any language change.

Summary

We hope it's clear from this text that Visual Basic shouldn't become a clone of C#. We also understand that Visual Basic is not supported in certain project types (Xamarin/MAUI, Blazor, ...), even if we would love it. Microsoft and Visual Basic should focus on project types where Visual Basic is strong (WinForms, web services, Windows services, ...). Nevertheless, we believe that certain features would make Visual Basic even stronger, without introducing the unnecessary complexity of C# in recent years from our perspective. We would like to thank Microsoft, especially the WinForms team, for supporting and maintaining Visual Basic for such a long time. Each of us can also program in C#, but we often choose Visual Basic because it is easier, clearer, and more understandable. It is the old, experienced, and smaller brother of C#, which does not tolerate every quirk, but in our opinion, still deserves to be maintained even in old age.

Best regards,
some professional Visual Basic programmers

Notes:

• This text was translated with ChatGPT, by the way a cool tool also for Visual Basic programmers
• This text reflects our feelings and experience and can be discussed. It is not a text that will be seen and supported by all Visual Basic programmers, which is also completely legitimate.

[aa4e]

Agreed

[KathleenDollard]

Thank you. For now I just want to let you know that we do see this and appreciate the thought put into it. Will respond more fully later.

[pricerc]

@KathleenDollard

Since this is 'fresh', perhaps I can offer a related perspective.

Like the authors of this open letter, I don't see much value in many of the recent changes to C#.

But the changes to the C# language don't bother me. I don't want VB to be C# with words.

It's the changes to the framework that have broken VB that bother me. And that's certainly the vibe I get from most VB commentators.

.NET is supposed to provide a language-neutral ecosystem that enables the peaceful co-existence of many languages.

Microsoft long professed a commitment to maintaining VB as a "first-class" language within that ecosystem.

Except some recent changes to .NET have been breaking changes with respect to VB.NET. There are examples on this forum, and elsewhere, that highlight examples of this. This letter highlights some affected areas.

As long as both languages are targeting the same .NET version, a class written in (for example) C#, should be consumable without ceremony or 'hacks' in VB (or any other "first-class" language). And without having to write C# "proxy" shims.

If .NET (the framework) is going to add new features such as those identified in the letter, then these features should be available for use by any "first-class" language. Otherwise, that language is no longer a "first-class" language.

[StefanDirnberger]

You are completely right with your letter.
We are developing professional applications with VB since VB 4 and we made the step to VB.Net with our fist apps rather late may be 10 years ago, because it was much easyer and more effective to move all our calculating logic to VB.Net than to any other language, including C#. Especially we have still a lot of VBA Macros in office and there it is so much more effective to copy code between VB.net and VBA. At that point we relied to MS that VB would stay a first place citicen, too.
For us it is completely useless to switch to C#. But on the other hand we only seldomly missed functions in VB.Net especially the new ones in C# wouldn't give us any benefit.
But after each new .NET Version we are looking, if there will be further support for VB. At the end this is not very funny.

@skurth so you are absolutely right with your statemant and we agree fully to you.
Let's hope that MS will supprt us further on...
KR
some more VB programmers ;-)

[VBAndCs]

@skurth
@StefanDirnberger

There is already a pre-release of the next VB.NET generation, called ModVB. It is forked from Roslyn by @AnthonyDGreen, the former PM of VB.NET before he left MS e years ago. ModVB willl go beyond all yopur expectations, not only at the syntax level like supporting JSON literals and patterns, but also it will provide support for AASP.NET core, Blazor, MAUI, so, VB.NET can get out the win desktop cage.
Right now, you can already design VB.NET views in ASP.NET core with Vazor, and write Records in Vb syntax with RecGen.
I also evolved MS Small Basic to Small Visual Basic to provide an easy and attractive entry point to VB.NET for kids and beginners, hopping that we can pass our love for VB to a new generation. It is also an open source fully written in VB.NET, so, it can be an easy training playground in compilers and their tools, before diving into Roslyn and contributing to ModVB.

[skurth]

@VBAndCs

Looks very exciting and thank you for the information. I was already familiar with ModVB, but I have only followed it peripherally. I would like to mention a few points to perhaps make our perspective a bit clearer:

a) I think it's absolutely fantastic that VB is receiving so much love from the community, and that such cool projects are emerging from it. For us (as a company), it's especially important that we can continue to develop existing software (for us, WinForms and services). Therefore, it's more important for us to have advancements in the language itself, rather than necessarily having to come up with new workloads (Blazor, MAUI, etc.) with VB. Even if we would love VB support in those workloads ;-)

b) This is again from the perspective of the company: I'm not sure if we can justify relying on features developed by individual persons or small teams, especially when they involve fundamental things like the compiler. We rely on the basics being stable and maintained, so that we can use these features.

c) As you mentioned, ModVB is based on a fork of Roslyn. What happens if there are changes/corrections to Roslyn itself? Are these changes incorporated into the fork? This ties into the same point as b).

Therefore, from the perspective of the company, it's more important for us to use widely supported products to develop our software. That's why we would prefer official adaptations to VB. Please don't misunderstand me, I think these projects are great and I will definitely be looking into them, but I'm not sure to what extent they should be used in professional software. But perhaps someone can alleviate my "fear" a bit ;-)

[VBAndCs]

@skurth
I understand your fears, but note that:

1. MS is leaving VB.NET behind for 6 years now. All your points makes no company create new projects with VB. They use C# or a non MS product.
2. Anthony was there from day 1 in planning and implementing Roslyn and its VB.NET part. I can say that Anthony is the key player in VB.NET on Roslyn, and VB.NET is actually frozen after he left MS (whether it is a coincidence or not. I have no info about that)
3. Anthony pulls new updates from Roslyn to his fork, and thankfully to MS, there is too few changes in VB.NET compiler over years, so it is easy to track them. Other changes in Roslyn out VB.NET are also easy to merge in ModVB, as there is almost no change in them in ModVB.
4. Bill gates and his fried started all this empire from scratch. One professional person is more than enough to build on top of it!
5. ModVB source is not published yet (not even released). I think no one can relay on it in business until it is open sourced.
6. I remember that Anthony mentioned something about creating a non-profit foundation for ModVB, so, it will be no longer a one person work. VB companies can contribute to this foundation to get the support they need.
7. After ModVB is released, I wish we can ask Bill Gates for a big donation. After all, VB is Gates legacy, and I expect he will not allow it to go to oblivion.

[ocdtrekkie]

I will note that while small, Microsoft did publish this yesterday, which at least was a nice indication they notice we exist: https://devblogs.microsoft.com/dotnet/update-to-winforms-vb-appframework/

[LeshaNewsomc]

Your suggestions for how Visual Basic could be continued in a reasonable framework are interesting. The idea of accepting pull requests from the community for Visual Basic would certainly be a democratic and community-driven approach to development. An annual survey among Visual Basic developers on which features from C# should be adopted in Visual Basic could also be a valuable way to gauge the community's preferences. Finally, Microsoft determining on its own which features make sense in Visual Basic would likely ensure that the language continues to evolve in a way that is consistent with its existing syntax and features.

In summary, it's clear that you have a passion for Visual Basic and believe that it still has a valuable role to play in the software development world. While I can't speak to Microsoft's plans for the future of Visual Basic, I appreciate your suggestions and hope that they will be taken into consideration.

[skurth]

@VBAndCs
Thank you for your listing. We will definitely take a look at it, especially once it becomes open source and is maintained by more than one person.

In our company, there are dozens of computers that build the programs (developers, manual testing, automatic testing, build servers, etc.). It won't be easy to replace the compiler for all of them ;) I'm also not sure if it's worth it for our WinForms application. However, if it's for other types of projects, it may be different.

@ocdtrekkie I don't think the last two comments are from Microsoft... Looks more like GPT-bots :( @KathleenDollard

[VBAndCs]

@skurth
ModVB will not replace VB.NET. It is a VS extension that you set up in a separate VS hive not to affect the main VS hive. ModVB is activated only in VB.NET projects that install some NuGets. So, you can still have both VB.NET and ModVB projects together in VS.
Once again: Anthony is the Master of VB.NET. If you trust Vb.NET, then you should trust ModVB.

[ocdtrekkie]

@skurth Ugh, looks like you are right. Ew.

[kingtu]

Our company has developed a large number of enterprise information management platforms using VB. NET, and we hope that Microsoft can continue to support VB. Net to keep up with the pace of modern languages.

[kingtu]

Our company has developed a large number of enterprise information management platforms using VB. NET, and we hope that Microsoft can continue to support VB. Net to keep up with the pace of modern languages.