For the better part of the past year, message boards and e-mail discussion lists all over the Internet have carried a running debate over the merits of Microsoft’s VB.NET compared to C#. The central question behind most of these discussions is usually, “Which should I learn first, VB.NET or C#?”

My purpose here is to help you find an answer to that question. Not by swaying you in one direction or another (despite my well-deserved reputation as a VB guy) but instead by dispelling some common myths so that you can make your own informed decision about which language you’d be most comfortable with. I’ll be ignoring the usual syntax quibbles, such as “C# has too many braces,” “VB.NET is too wordy,” and “I hate C# (or VB.NET) because it is (isn’t) case sensitive,” here. Syntax is primarily a matter of taste. Instead, I’ll concentrate on some of the technical arguments I’ve seen advanced for both languages.

The case for C#
As the newest language in the Microsoft stable, and due to its undeclared status as the company’s private little version of Java, C# gets a lot of attention. Some people seem drawn to the language simply because it is the newest, and developers always want to play with the newest toy. Others prefer a C# world for reasons that are more concrete.

The prevailing premise doesn’t hold water
“If I have to learn a new language anyway, I might as well learn C#.” This is probably the most common argument you’ll hear. The reasoning goes something like this: “VB.NET has changed so much from VB6 that it’s basically a new language. If I’m going to have to learn a new language anyway, it might as well be C#, since it was designed specifically to work with the .NET class libraries.”

This is also by far the weakest argument I’ve heard for one side or the other. You could just as validly argue that if you have to learn a new language anyway, it might as well be VB.NET—after all, it’s a new language too. Let’s also remember the reason why VB.NET was altered so radically from its progenitors: It was redesigned specifically to work with the .NET class libraries.

Managed vs. unmanaged code
“C# lets me write unmanaged code, which runs outside the CLS memory manager’s control, can access memory directly, and make use of pointers. Running code without the overhead involved in the use of managed memory should confer a hefty performance gain.”

There are three problems with this statement: First, no one should talk performance figures when working with a beta development environment. Case in point: There was a noticeable managed code execution speed improvement between .NET betas 1 and 2. Second, the jury is still out on how much of a performance gain unmanaged code enjoys over managed code and whether the risks are worth that gain. Check out this MSDN article by Eric Gunnerson for more information. Third, although VB.NET cannot create unmanaged code, it can, through the use of the System.Runtime.InteropServices namespace, access and work with unmanaged memory.

C# has built-in XML documentation
“The C# compiler includes support for XML documentation embedded directly into the source code. If I use C#, I write my code and its documentation at the same time.”

Anyone who has ever used JavaDoc knows how useful it is having your documentation embedded in your source. Both code and documentation can be updated simultaneously, so, in theory at least, your docs never become outdated. However, it’s been my experience that a relatively small percentage of Java developers actually use JavaDoc. So, the question becomes “Will you use it?” If your answer to this question is “Yes,” you have a compelling reason to check out C#. (Note to Microsoft: Put this in VB.NET as well, please. Seriously, how hard can it be?)

What about VB.NET?
VB has a reputation as a toy language among “real” developers, and in some cases, that reputation is deserved. Heretofore, VB has been hamstrung by more than a few annoying weaknesses. VB.NET, however, is just as powerful a .NET development language as C# is. Some would say it’s more powerful.

VB.NET has built-in (insert feature here) support; C# doesn’t
“VB.NET has built-in support for a number of things, such as string manipulation (Mid, InStr, and so on) and type conversions (e.g., CInt), among others. C# lacks this built-in support, so these things, which I need routinely, are more difficult to carry out in C# than in VB.NET.”

Before you hold up the Mid or CInt functions as the ultimate evidence of VB.NET’s triumph over C#, you really should check out the Microsoft.VisualBasic namespace. You’ll find most of VB.NET’s built-in commands and utility functions there. Since these functions are kept in a namespace, any CLS-compliant language can use them, as Listing A illustrates. This kind of undermines that argument, doesn’t it?

Better binding support is unsupported
“VB.NET has better support for binding to COM objects.” I’ve seen this one only a few times and never with any supporting reasoning. From what I’ve seen so far though, this simply isn’t true. Both C# and VB.NET must use runtime callable wrappers and an equivalent amount of code to work with early-bound objects. Likewise, working with late-bound objects requires a similar amount of code.

VB.NET uses background compilation in the IDE
If you can say nothing else nice about the VB development environment, you have to at least admit that its source editing features are without equal. You can literally debug your code as you type it. The trouble is, that stupid compile error message box always gets in the way, and the ding sound can scare the wits out of you if your speakers are turned up a little too high.

Visual Studio.NET eschews the “scream at you until you fix it” approach in favor of the more passive error notification system pioneered by Microsoft Word: the tried-and-true “put a little squiggly line under each error” system.

In all seriousness, VB.NET’s background compiler/syntax checker is very sophisticated and unobtrusive. In some cases, it’s even capable of telling you exactly how to correct whatever problem it discovered in your source. While C# has its own syntax checker, which does a nice job of matching braces, counting parentheses, and showing you missing semicolons, it simply doesn’t match VB.NET’s version for ease of use.

It really is a matter of style
I hate to break it to the people who are still arguing over the question of superiority, but Microsoft is telling you the truth when it says that all .NET languages are created equal. Those who maintain that C# is somehow better than VB.NET (or vice versa) and that developers who know it will command higher salaries have got it all wrong.

The emphasis, at least among most tech-savvy companies, will rapidly shift from seeking developers with particular language experience to seeking developers with demonstrable .NET class library knowledge. So my advice to you is don’t overly concern yourself about the choice: Pick whichever language looks interesting and learn to use the framework classes with it. Then, if I do turn out to be wrong, and the market does wind up favoring one language over another, it’ll be a simple matter for you to pick it up, jump on that bandwagon, and laugh at me all the way to the bank.

What will you choose?

Which way do you plan to go: C#, VB.NET, or neither of the above? What is your reasoning? Send us an e-mail with your thoughts or post a comment below.