C# or VB.Net you ask? I say either. Then why the heck am I 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 to 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!
March 27, 2006 at 12:17 pm
Manivannan, a team leader at Cogent Innovations wrote in a group and i quote that here:
“The choice between C# and VB.NET is largely one of subjective preference. Some people like C#’s terse syntax, others like VB.NET’s natural language, case-insensitive approach. Both have access to the same framework libraries. Both will perform largely equivalently (with a few small differences which are unlikely to affect most people, assuming VB.NET is used with Option Strict on). Learning the .NET framework itself is a much bigger issue than learning either of the languages, and it’s perfectly possible to become fluent in both – so don’t worry too much about which to plump for. There are, however, a few actual differences which may affect your decision:
VB.NET Advantages
> Support for optional parameters – very handy for some COM interoperability
> Support for late binding with Option Strict off – type safety at compile time goes out of the window, but legacy libraries which don’t have strongly typed interfaces become easier to use.
> Support for named indexers (aka properties with parameters).
> Various legacy VB functions (provided in the Microsoft.VisualBasic namespace, and can be used by other languages with a reference to the Microsoft.VisualBasic.dll). Many of these can be harmful to performance if used unwisely, however, and many people believe they should be avoided for the most part.
> The with construct: it’s a matter of debate as to whether this is an advantage or not, but it’s certainly a difference.
> Simpler (in expression – perhaps more complicated in understanding) event handling, where a method can declare that it handles an event, rather than the handler having to be set up in code.
> The ability to implement interfaces with methods of different names. (Arguably this makes it harder to find the implementation of an interface, however.)
Catch … When … clauses, which allow exceptions to be filtered based on runtime expressions rather than just by type.
> The VB.NET part of Visual Studio .NET compiles your code in the background. While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger.
C# Advantages
> XML documentation generated from source code comments. (This is coming in VB.NET with Whidbey (the code name for the next version of Visual Studio and .NET), and there are tools which will do it with existing VB.NET code already.)
> Operator overloading – again, coming to VB.NET in Whidbey.
> Language support for unsigned types (you can use them from VB.NET, but they aren’t in the language itself). Again, support for these is coming to VB.NET in Whidbey.
> The using statement, which makes unmanaged resource disposal simple.
> Explicit interface implementation, where an interface which is already implemented in a base class can be reimplemented separately in a derived class. Arguably this makes the class harder to understand, in the same way that member hiding normally does.
> Unsafe code. This allows pointer arithmetic etc, and can improve performance in some situations. However, it is not to be used lightly, as a lot of the normal safety of C# is lost (as the name implies). Note that unsafe code is still managed code, i.e. it is compiled to IL, JITted, and run within the CLR.
Despite the fact that the above list appears to favour VB.NET (if you don’t mind waiting for Whidbey), many people prefer C#’s terse syntax enough to make them use C# instead.”