What's so wrong about Microsoft.VisualBasic functions?

Sorry, I don't necessarily agree with everything said in third comment of this post. Don't get me wrong: I strongly encourage using the BCL whenever possible.

But, as for there being performance problems, that's the same logic that people are using when they say that VB.NET is slower than C#. The VB.NET team (and Carl Franklin) would take exception to that.

The reason is because this is just a .NET class library, which is really no different than if you wrote these helper classes yourself in C# and included it within your class library. I mean, do you really think that the VB.NET team would not optimize their code before releasing it to millions? Because they program in VB, they don't know how to make small code?

Also, this is the Microsoft.VisualBasic assembly, not the Microsoft.VisualBasic.Compatibility assembly that the post is discussing.

For example, let's disassemble the Right() function as C# to see what's going on:

public static string Right(string str, int Length)
{
   if (Length < 0)
   {
      throw new ArgumentException(
      Utils.GetResourceString("Argument_GEZero1", "Length"));
   }
   if ((Length == 0) || (str == null))
   {
      return "";
   }
   int num1 = str.Length;
   if (Length >= num1)
   {
      return str;
   }
   return str.Substring(num1 - Length, Length);
}

Ok, sure, it's more efficient to just use Substring() directly. I'll give you that. But, this is an all-purpose function that every VB'er already knows. The flexibility adds a little bloat, but you can use it anywhere. Is it so wrong to link to a class library to use this function just because that class library has "Visual Basic" in it's name?