In the comments on my post on language choice, Patrick asked “isn’t C# the language that’s most ‘native’ to the .NET environment?” Christopher then follows up with a related question as to whether developers should use functions in the System namespace instead of ones in the Microsoft.VisualBasic namespace because the former might be faster. We see these kinds of questions fairly often, so it’s worth discussing them a little bit.
Before going any further, I’d recommend that people who have questions like this take a look at an article that Derek Hatchard and Scott Swigart wrote for MSDN entitled “Visual Basic .NET Internals”. It looks at a bunch of these issues in detail and is an excellent place to start on this question.
The bottom line, though, is that there is no language that is ‘native’ to the .NET environment. While it’s certainly true that there was no language called ‘C#’ that existed before .NET came into being, one of the major selling points of C# is that it is an amalgm of the syntax and features found in C, C++, Java and VB, adapted for the .NET platform. In that sense, it is exactly like Visual Basic on .NET – an adaptation of a previously existing language (just as C++ and Java were, in turn, adaptations of C, which was, itself, an adaptation of prior languages). Both C# and VB were designed to work well with .NET, and developers can choose either language without any concern about access to the fundamental capabilities of the .NET platform, because they both compile down to IL in the end. The only differences you’re going to see between the IL the two languages generate is when one language does something more for you than the other language does (or we have a bug, in which case, let us know about it).
The question of the Microsoft.VisualBasic namespace is similarly straightforward. The base class libraries (i.e. the System namespace) provide a huge amount of functionality which both C# and VB give you full access to. The functions in the Microsoft.VisualBasic namespace are built directly on top of the System namespace and provide functionality that goes above and beyond the functionality that the System namespace provides. As such, there is no real reason not to use the functions there because they provide you “all the features of the class libraries and more.” (And we’re going to go even further in VB 2005.) Having said that, there may be situations in which you may want to sacrifice some of the extra functionality for a little more performance. This is the same kind of tradeoffs that you have to make with the System namespace, and so if performance is critical, it’s always important to understand the functions that you’re calling (the paper linked to above talks a lot about this).
The problem with blanket pronouncements like “always use CLR functions instead of VB functions“ is that you can easily shoot yourself in the foot without knowing it. One suggestion I’ve seen in more than one place is to use the functions exposed by the Convert class (a CLR class) instead of the intrinsic conversion operators (CInt, CStr, CLng, etc.) exposed by the VB language. This is supposedly because the CLR functions are going to perform better than the VB “functions.” The problem with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions. This means you’ll get significantly worse performance by calling Convert.ToInt32 instead of using CInt. So it’s always very important to know what you’re doing when you start tackling issues like performance.
So, in the end, there is no “native” language on the CLR and performance is something you’re going to have to think about no matter what language you choose. (In fact, I think I should add a rule #0 to my “Ten Rules of Performance:” When it comes to performance, beware rules.) There are certainly lots of other factors to think about when choosing between VB and C#, but I don’t think these are two of them.