Choosing between Visual Basic .NET and C#
August 8, 2011 Leave a comment
This questions pops up from time to time on community web sites or at some customers facing a choice situation. Although many people argue on the technical virtues of each language, it seems to me that this should not be a technical decision.
On the technical side, it is important to remember that both languages in their current version were designed for the .NET platform. Because of this, Visual Basic .NET and Visual C# .NET use the common language runtime and provide no significant performance difference, except from marginal ones on some very specific points at the compiler level. A few things were missing in Visual Basic before .NET version 2 but this was quite a long time ago now. For people who want to know more on the technical side, we recommend this technical comparison as well as this syntax comparer.
Some design decisions, especially at the syntax level, were made to facilitate transition of existing communities: C# was primarily targeting C++ and Java developers whereas VB.NET was designed to address former Visual Basic developers. Because C++ was more powerful than Visual Basic – in the sense one could do things in C++ that one could not do in VB – there are still people arguing that C# is for professional developers and Visual Basic .NET for hobbyists. There is no technical fact to support this assertion and as Microsoft states: "Although there are differences between Visual Basic .NET and Visual C# .NET, both are first-class programming languages that are based on the Microsoft .NET Framework, and they are equally powerful."
This said, there are a couple of business factors that need to be considered when making a programming language decision.
As a primary element, the skills of your development team and their experience with one syntax or the other will be of primary importance to get the relevant productivity, especially if your team is stable and committed to your organization over the long term. It would be counter-productive to force a language change when people are comfortable with their current programming style and when there are no strong reasons to change.
On the other hand, if your project requires hiring numerous new people, it might be easier to get resources on board for a C# project than a Visual Basic one. Also because of the history mentioned above, it might be frequent that more advanced developers use C# than Visual Basic .NET.
In some cases, mixing languages can also be achieved through interoperability. Doing this requires the critical mass of code and resources on both languages to be economically justified, otherwise it will turn being suboptimal for maintenance of your code base over the long term.
What happens very often is a situation where there is some Visual Basic history and legacy code, but a decision was made to migrate to .NET while strongly revisiting the approach: from an old-style procedural programming to object-oriented, a waterfall to agile methodology change, deployment of Visual Studio Team System, hiring of new resources and organizational update,… In that very common scenario, it might not be relevant to stick to Visual Basic as the language just because of the legacy. In fact, it might also be a good move to formalize the change by switching to C#, because you won’t be able to use the same program structures anyway.
The ultimate argument that often pushes the decision towards C# is the community. Many code samples, published by Microsoft or the community, are in C#, which will make your team much more productive as the bottom line in many scenarios. And as a consequence, you will find a more complete ecosystem of third-party components and tooling for C#. This is what I end up with in many real world customer situations I faced.
To conclude, in case you need to switch because of your own personal career path, Visual Studio Magazine is your friend:
Daniel COHEN-ZARDI, CEO