C# or VB.Net you ask? I say either. Then why the heck is this here? I will tell you.

I will say what you are probably hearing everywhere first: It's just a matter of preference really. The difference is so trivial and little, that in business projects, it really doesn't matter which language is chosen for coding. The database transactions will slow down the code to an extent that the performance difference between C# and VB.Net - if any - is nullified. On a more personal take, I frankly think VB.Net is being maintained only because at the time of launching .Net, VB was the most extensively used development platform in businesses.

On a more technical note, I would say C# - as in all C? languages - enjoys more power in the form of unsafe code, better compilation, etc - albeit trivially. VB.Net on the other hand, had a super cool IDE, great intellisense, easier refractoring and reports say it takes 20% less time to code in VB.Net using Visual Studio than in C#. Another tilt in favour of VB.Net could be that it has more of an intuitive flow in it. It's almost like just talking to the IDE. Dim o As Object is more intuitive to some than a Object o;. This really helps if you are a not-so-geeky programmer and just wants to get things done. And in feeling comfortable. If our code is more readable, we can work longer, and without even realizing it we would feel much better. Trust me, I am a C# programmer mainly and I have had to do a lot of partial projects in VB.Net. I was certainly more productive in C#. Not that I didn't know the VB.Net way of life - when I sat down and thought about it, i realized it was, indeed, the readability. It was the 'feeling'.

One thing the C# guys could have done is made the semicolon (;) an optional entity. Come on, are modern day compilers so dependent on that tiny little semicolon for lexical analysis? Pure performance wise, the MSIL generated for a C# code is usually much smaller than an equivalent one for the same functionality in VB.Net.

We are really limiting ourselves if we study only one language, on a side note. As my title says, I cannot help you choose. Spend that extra week learning the language you don't know. Then decide. It's very important that you fully understand both sides of the story before saying this is the better one as far as I'm concerned.

In one line, VB.Net is for productivity and C# for power/performance. VB.Net can be freely used in businesses and come to C# if you want to create games, and other hardware intensive stuff. Stay away from C++ as much as possible, seriously. Not that these differences are significant enough to partition the languages. Well, I told you I cannot help you choose!

I picked this up from Microsoft's Shared Source Initiative website. A lot of people have this idea that open source means Linux and hence its a war between the open source community and Microsoft. As the following text clearly speaks out, it is a combination of the two that is to be desired.

"Microsoft has been learning from the OSS community regarding the benefits of deeper collaboration and increased transparency leading to better communication with customers. We believe the most effective pathway for a commercial software company is to strike a balance between investing in research and development and the release of intellectual property assets in the form of source code for both reference and collaborative purposes.

The increased competition resulting from the proliferation of OSS has been constructive for the industry as a whole. The implications of OSS within multiple market segments are causing organizations to figure out what is most important to them. It has placed a higher premium on innovation and a drive to deliver greater value for lower costs. The big winner in this equation has been the software consumer, whose choices have increased dramatically.

The Shared Source Initiative is the manifestation of these factors within Microsoft. With more than 80 source code offerings being used by more than two million developers, Microsoft is looking to apply the best of open source while helping its customers avoid many of the model’s pitfalls. There is no one, correct way to create software. The ecosystem as a whole will benefit from a rich tapestry of development, business, and licensing models."