My recent posts on VB performance isn't an attack on the language; it was just on the current implementation. In some cases, designers have implemented a language feature in an expensive manner using reflection, when a superior method with a 10X-100X performance improvement was available.
I just read a post claiming that my post is an indication that VB programmers should get with the program and use C#. I measured VB through one yardstick, performance. While VB tends to do a lot more checks, which can hurt performance, they actually help programmer productivity. In any case, the performance differences between the two languages have little impact in most applications. Often, the performance overhead can be worked around, and there aren't many C# tasks that VB cannot also accomplish.
With the new features coming in the next version of VB.NET, programmers are likely to be substantially more productive than C# programmers for a certain class of common applications, because of features like the simplified My.* namespaces and Edit-and-Continue. The language does hide a lot of details, but that can also reduce the number of coding distractions.