email article printer friendly

C# vs.VB.NET:Choosing Your .NET Tool
It’s not as easy to decide as you might think
by Juval Löwy

All .NET components, regardless of the language they were developed in, execute in the same runtime called the Common Language Runtime (CLR) environment (hence the name). The CLR is like a warm blanket surrounding your code, providing it with memory management, a secure environment to run in, object location transparency, concurrency management, and access to the underlying operating system services. Existing compilers produce CLR-ignorant code—that is, code that does not comply with the CLR type system and code that is not managed by the CLR. Visual Studio .NET comes with four CLR-compliant languages: C#, Visual Basic .NET, JScript .NET, and Managed C++.

JScript .NET and Managed C++ are mostly for migration proposes, and it is safe to assume that the majority of .NET developers will choose to disregard them.

The real question for the .NET developer is: Should you choose C# or VB.NET?

The official Microsoft party line is that all .NET languages are equal in performance and ease of use, and therefore choosing a language should be based on aesthetics and personal preference. According to this philosophy, if you come from a C++ background, you will naturally pick up C#, and if you come from a Visual Basic 6 background, you will select Visual Basic .NET. I believe that basing the decision merely on your current language is wrong, and that you have to look not at where you’re coming from, but where you’re heading. Let me explain.

The developer community today is roughly divided into two types: the rapid application developers and the enterprise (or system) developers. The two types address different business needs and use different tools. Rapid development today is easier in VB6 than with C++ tools such as MFC, while at the same time, because of its inherently messy nature, VB6 does not lend itself well to large, maintainable applications. In addition, VB6 has built-in limitations that impede scalability (lack of multithreading or object pooling support), and the VB community as a whole lacks the matching development skills to do system or enterprise development.

C++ developers, on the other hand, have access to unlimited power (as well as liability), but mastering ATL or MFC might take years. Applying object-oriented analysis and design methodologies in a large application requires a great deal of skill and time, and will result in unmaintainable code if you do it poorly.