ASP.NET - C# vs VB.NET - Indirect differences and things you might not initially consider

I'm not interested in starting another "who has the bigger member" VB vs C# debate (https://stackoverflow.com/questions/158229/what-are-the-pros-of-vb-net seems to cover that already) though I am interested in indirect differences which may influence developing in one vs the other. All my commercial .NET development was desktop apps in VB until the last 3 months where I had a web project and decided it was a good opportunity to force myself to learn C#. In the course of doing so I've noticed a few non-technical differences:

• A lot more mature open source apps and thorough examples are available in C# than for VB.

• Third party vendors of add-ins for things like refactoring and documentation tend to support C# better than VB (if at all), with VB support for similar features from comparable C# versions often lagging behind or absent.

• ASP.NET jobs targeting C# seem to pay around 15-20% more on average than otherwise identical jobs in VB (at least in Australia, looking on seek.com.au and careerone.com.au for reference).

The jump to ASP.NET, MVC and C# presented a lot of speed humps at once but I think was well worth it. The decision I need to make now is whether to put more energy into pursuing C# for future .NET development or if I might as well stick to VB. Are there an开发者_JAVA百科y other points of difference between the language (other than direct language feature comparisons already covered) that one should consider in this instance?

I find that VS does more automatic code completion for VB than C#.

It's very useful to know both languages and I personally have to get better acquainted with C# so that I'm comfortable applying for C# jobs which should triple my options.

• At the Microsoft 2009 Mix Web developer conference, all the presentations that I attended included code examples in C#, not VB.

• In StackOverflow, notice how questions tagged c# largely outnumber vb.net and vb.

• John Skeet wrote C# in Depth, not VB in Depth.

One thing that has been widely stated when I have participated in hiring (both as a hiring manager, as well as a candidate) is that C# and Java are close enough that converting a candidate from one to the other is fairly easy, and that this is not true for a VB.NET candidate to C#, or Java. This statement has even been extended to C++, saying training a C# or Java developer (to code in C++) is easier than a VB.NET developer.

Though I tend to disagree (I think it is more about how the person sees programming in general) I know that several large, reputable firms will accept candidates for C# or Java jobs that list C++, C# or Java experience. These same firms will in general not look at candidates who only list VB.NET, or list VB.NET as their primary language.

Specifically for web development, becoming proficient in C# made writing javascript (and doing complex things using jQuery) much easier because the syntax is so similar.

I agree with your points, particularly the first. I would add that it seems there are more C# developers out there than VB.NET. If you are looking to hire another developer, you may get more (quantity or quality) from the C# pool. And employers, perceiving that C# is more popular, will go in that direction, and there will be more demand for C# programmers (hence the higher salaries/rates you noticed)

I know that this is an old post but I'd like to add one other factor: all the new stuff gets done in C# first. This comes from my experiences with early WPF development. All the examples where in C# and we were working in VB.Net. It just took extra time to translate. Another example is lambdas, initially you could use expressions (single line) or statements (multi-line) in C# but only expressions in VB.Net.
When .Net was first rolled out, I think that there were a lot of VB6 folks who didn't really get .Net and that it was a whole different animal. I think that those people were partially responsible for the negative perceptions of VB.Net. But that was 10 years ago now and no longer a factor.