I've been in workplaces where, at the start of a project, the "Should we use VB.Net or C#" question has been raised.

Granted, it's probably less common to have to make that decision now than it was in the early days of .Net, particularly given the trend towards language convergence, but it can still be a heated debate.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Mark Trapp May 3 '11 at 17:48

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

2

Just to throw a spanner in the works, there are some products (e.g. WF designer in VS2010) that only support VB.Net syntax...
–
DamovisaSep 7 '10 at 23:56

20 Answers
20

I started as VB.NET programmer but with passing of time it became obvious that quite a lot of new features are coming first to C# and then later to VB.NET (e.g. automatic property). And community surrounding C# is much more lively than VB.NETs one.

Additionally, if you intend to learn Java or similar language, C# is better starting point - syntax is almost same in all C-derived languages. Although this would not be tipping point for me since syntax is something you can learn quickly anyhow.

With each generation of tools, the "features" arguments shift a bit. The only thing I can think of which C# has as of vs2010 which vb.net lacks is iterators; by contrast, vb.net offers named indexers, exception filters, XML literals, a an "Is" operator that's 1000x better looking than Object.ReferenceEquals, event handling that's almost done right, and a smoother IDE experience. VB.net makes it possible, albeit slightly awkward, to have field initializers use constructor parameters or safely create IDisposable objects without having to use ThreadStatic variables; C# does not.
–
supercatJul 18 '12 at 15:32

Well, today there's little to none real reason to use VB.net. In the beginning it was just a way to give give VB programmers a familiar syntax, but was essentially a BASIC-like remapping of C#. So its only real advantage is a more familiar syntax, and its BASIC syntax is also its real only limit.

Over the time the two languages evolved alongside, the only significant difference is the my pseudo namespace.

I would advice every .net programmer that is not familiar to C# to learn it, as the community is fairly larger and the C-like syntax is common to most of the more used languages.

I prefer the bracket syntax of C-style languages to the more "verbose" syntax of BASIC-style languages.

My introduction to programming was with Turbo Pascal. (The bit of BASIC programming I did on the Commodore 64, as a child, doesn't really count.) After learning Java I never looked back and have preferred C-style syntax.

They are functionally the same, there is nothing you can do in one you can't do in the other, and for the future Microsoft have pledged that the language teams will develop both evenly so this is equivalence unlikely to change.

I hate VB.NET. The days I still spend using it are the days I regret. That said, my tastes are a part of my situation and experience, and don't necessarily have any relevance to what you're doing...

I think it is important, when comparing continually-evolving languages like C# and VB.NET, to look back at their history and see how they arrived at their current state:

The original advantages of BASIC on microcomputers included size and simplicity (small, easy-to-parse syntax made for small, reasonably fast interpreters and left room in memory for the actual program and data), an interactive environment that enabled experimentation, and a syntax that eschewed terse symbols and structures for a reasonably clear, English-like syntax. It was poorly-suited for large, structured programs however, and tended to encourage spaghetti code. Still, its availability and simplicity made it an excellent choice for an introduction to programming.

QuickBasic updated the syntax to allow for large more structured programs, and added compilation for faster execution.

VisualBasic provided a powerful, easy-to-use form builder to enable rapid construction of GUI applications, while adopting the QB syntax for use in scripting these UIs. It worked best when used to create UIs for low-level logic provided as pre-built components (usually written in some other language). Over time, the syntax became increasingly large and inconsistent as new features were tacked on. The focus on drawing up a UI first and then filling in bits of script worked well for small, UI-centered apps, but tended to encourage copy-paste programming and a variation on spaghetti code while discouraging re-use, complex data structures, and separation of concerns. In the minds of many, "VB code" became synonymous with "big ball of mud"; "VB programmer" with "inexperienced hack".

VB.NET is a VB-like language on the .NET platform, an attempt (not entirely successful) to clean up and modernize the overgrown VB syntax. It was not perfectly compatible with existing VB code, and made no effort to provide compatibility with VB forms (arguably the most important part of VB) whatsoever. This left many VB product owners with the unpleasant choice of effectively re-writing their applications in VB.NET (dealing with subtle incompatibilities in every routine that wasn't carefully examined) or actually re-writing their applications in C# (dealing with an unfamiliar syntax in addition to the new runtime library and forms designer). Most VB.NET users were VB users who stuck with it for the syntax alone, many using it as a crutch while learning C#. As a result, it immediately took on a reputation as a haven for programmers who had become stuck in their ways, unwilling or unable to expand or improve their skills.

At this point in time, VB.NET continues to evolve, slowly shedding baggage while picking up new and interesting syntax (LINQ, XML literals). Still, it retains almost none of the original advantages of BASIC: it is a large, complex language with a fairly steep learning curve and limited opportunity for interactive experimentation.

For old programmers who have stuck with it over the past 30+ years, it's not a bad choice, provided they don't limit themselves to it.

For new programmers, the increasingly-vague resemblance of VB programs to English is hardly worth the bizarre nods to backwards compatibility and social stigma.

For new projects, VB.NET is a strange choice unless the project is heavily involved with one of the few tasks the language is optimized for: integration with poorly-typed COM components (Office...) (though C# 4.0 reduces this advantage considerably), or inline XML generation.

With C# 4 I don't see any advantage VB.Net still has with regards to COM integration. I think inline XML generation could be a useful feature; I try not to use XML (and have been successful for the last 5 years!), but if I have a .net project that needs to generate lots of XML I'll probably create a VB project just for the XML generation.
–
configuratorSep 26 '10 at 3:43

3

I was enjoying reading your answer but it seemed to stop suddenly. You provide history of basic that is interesting and I assume correct. I was expecting to find out why you dislike VB.NET and/or why you like C#. "For new projects, VB.NET is a strange choice" Why?
–
Tim MurphyOct 8 '10 at 11:11

I've done a lot of work with VB.NET, but I understand enough C# to get the gist of what is happening in the code. My current preference is VB.NET because I am most familiar with it (obviously), but I don't really have a preference between verbose BASIC syntax and C-style syntax, both are very readable and understandable to me.

Most of my coworker's programming background is COBOL and VB6, so VB.NET was the more comfortable .NET language choice for us as a team. There wasn't a solid reason for us that made learning C# a requirement since they are functionally the same.

I´m in the same trouble. :) and I prefer VB.NET at the same way I prefer coke not pepsi. But, if we´ll starts a new project, C# is the best choice because we´ll find more programmers that knows and prefers C#. I understood that MS strategy for VB was to bring up VB community to the .NET plataform.
–
PagottiOct 8 '10 at 12:46

I'm familiar with both, but did a lot of my early programming work in VB4, VB5, and VB6. Now that both languages in .NET have gone through a few iterations and converged quite a bit in their capabilities I think the debate is downright silly, much akin to "what's your favorite color."

Personally, I like both of them for different reasons.

VB.NET
A lot of people talk about how the C# syntax is more intuitive, but that is very subjective and based heavily on what you started out knowing. I would argue that if you were completely objective VB.NET syntax is probably more intuitive if you don't assume prior knowledge in another language. For example, given the same program in C# and VB.NET which do you think would be more decipherable to someone who has no knowledge of programming. Seems pretty clear to me.

The other thing that is nice about this syntax, is that is is much more explicit about closing structures (END IF, END WHILE, NEXT X) compared to the bracketing model. It makes the code a bit more readable and often allows the compiler to be more precise in what line number exactly is causing compile errors. If you've ever gone on a missing bracket/semi-colon hunt because of a compiler error 50 lines away from the problem you know what I mean.

Also, in the VB.NET win column in my opinion is lack of ==/= as comparison/assignment operators. The rare benefits of having a distinct operator for each is never going to offset all the (sometimes) hard to discover foibles that it helps create.

Finally, I hate case sensitivity in programing languages. One of the complaints about VB is that it has so much baggage, but C# carried forward the albatross of C's case sensitivity. I have never been in a situation where I wanted two identifiers in the same scope to differ only by case. It just makes for busy work and slows me down. VB.NET gets some points over C# in this regard to me.

C#
Programmers love to be concise, which is why I think they generally favor this syntax. It just has a certain aesthetic appeal. However, from a completely practical perspective I like it because it is so similar to languages like Java, JavaScript, and C++.

Since I do a lot of web development that requires both server and client side programming, I find it easier to mentally switch between C# and JavaScript as I am frequently required to do.

Also I like the fact that, for the most part, that if I ever had to transition to doing Java or C++ programming, I would have a bit of a head start if I were using C# most of the time.

+1 for the web development comment. I use both VB.NET and C#, depending on the project, and find it much easier to go back and forth between C# and Javascript than VB.NET and JS.
–
PaperjamSep 8 '10 at 22:54

2

'I have never been in a situation where I wanted two identifiers in the same scope to differ only by case.' is pure subjective. This is exactly one of the reasons why I prefer C#. When applied correctly and consequent, it might make all sense to the world to have for example a parameter in the constructor with the name name and a public property with the name Name and then assign it through Name = name;. As long as you keep a coding standard, else I agree, then it can cause confusion.
–
AidiakapiOct 18 '11 at 11:52

1

Needing a coding standard to avoid insidious bugs like that, to me, is a negative. The presence of a workaround doesn't excuse it.
–
JohnFxOct 18 '11 at 12:31

VB.NET is entirely different syntax. C#, being similar to Java and other languages gives me a better position to quickly adapt to new things. Since the output of C# and VB.NET are virtually interchangeable, it makes sense to go with C#. Plus, if your company's code is in C#, you're more likely to be able to train a Java developer how to code C# than a Java developer VB. There are only subtle advantages, but subtle is still an advantage.

Here's a way of looking at it:
Between SO and CodePlex, which language is more popular? C# or VB.Net?

Sometimes, following the herd is a good thing because it's the herd that's going to be able to help you when you need it.
By default, C# will be faster than Vb.Net. I believe using Option Strict might equalize it though. The last time I compared IL between the two, VB.Net's type safety ended up adding about 15% more to the IL. This translates into extra overhead. AND... given languages that do basically the same thing, I'll take the faster one. My convenience should not override my user's experience in general.

Putting my personal preferences aside. As someone who's been recruiting (and trying to be recruited) lately, when we had this debate in the office the general consensus was that we should look to move to C# from VB.

Why? Because C# was more prevalent in the market (around us anyway), allowing us to recruit more easily, and be recruited more easily.

It looks like it's gone full circle; people learn C# because recruiters want it, because there are more candidates.

Being a somewhat older dev (is 59 "somewhat" older?), I learned BASIC first on a Commodore VIC-20, taught myself Turbo Pascal (v1!), went on to learn COBOL at college, and spent 14 years developing on IBM mainframes, with brief diversions writing a medium sized apps in Revelation BASIC (a variant of PICK BASIC) and a few utilities in Modula-2, before side-stepping over to VB5 and VB6. And then came .NET.

Because of my Basic background, I thought I should start out with VB.NET, only to find that I kept trying to do things the "old" way and it was driving me nuts (okay, more nuts). Being that I had done some work in C, I thought I would give C# a whirl to see how that went. And OMG, that was like emerging from a dark tunnel into clear daylight! Totally unexpected. And I used to make disparaging noises about C being a "write-only" language -- "so hard to understand that a C programmer couldn't figure out what his own code did 6 months after he wrote it", an observation made by semi-famous novelist that I thought sounded cute at the time.

So, by virtue of being a bit unfamiliar with C, C# was paradoxically easier for me to learn .NET programming in than the far more should-be-familiar Basic paradigm. I still like VB6, but have come to love C#. The best programming language on the planet.

I like to say that the only reason BASIC is still popular is that it was Microsoft's first product, and they've be shoving it down our throats for the past 35 years. It should have died a long time ago.

With that said, I've worked on two sizable .NET projects and both were done with VB.Net - though there was a bit of C# because either the translation was a bitch, or the construct didn't exist in VB.Net. The only advantage I see with VB.Net is that the Visual Studio editor is much more friendly to it (in my experience anyway) than it is with C# - Intellisense seems better, and so does autoformatting (note that since I have not used C# as much, I may just be missing something in the configuration of the IDE...)

A major disadvantage in VB.Net is that they brought in a lot of VB6-era crap way back in .NET 1.x to ease the conversion of VB6 code. That stuff is still in there, and VB6 coders are coding new code using those... "extensions" rather than using the more neutral .NET classes/methods/whatever. I don't know how many times I asked my boss why he still used that crap. "But... It works..." Right. Hey, I like to bitch.

While looking for help on the web, I found the vast majority of solutions were in C# - check out the MSDN forums, various blogs, etc... Books have a tendency to focus on C#, and if there is a VB version, it usually comes in months later (e.g. Pro LINQ.... from Apress.)

Many languages share the C ancestry, which makes switching between C, C++, C#, Java, PHP and a few others much easier. PHP is a bit of a stretch here, but it does have a lot of C-like constructs. VB? Well, it's pretty much its own little thing and that's that.

A project leader in my organization recently told me that more and more new projects are being developed using C# instead of VB - FINALLY. When .NET was introduced in our organization, they more-or-less-officially went with VB.Net because of all the VB6 coding that was already going on. The powers that be later admitted to me that that wasn't their best move.

As somebody else above pointed out, I wouldn't say no to a VB.Net project, but I'm still hoping that it will be slowly eradicated from newer development at my place of work.

In addition to the other answers posted here, I would choose C# over VB because C# programmers get paid more. More experience with C# = more $$ :)

I know both languages are almost the same and its really easy to switch between the two, but I think when management looks at a bunch of curly braces and semi-colons they accept the fact we are doing something they cannot do, where with VB.Net they might look at it and go "oh that must not be that hard to do if I can understand it".

I develop in Visual Basic .Net since 2001 and I love it and I hate it!!!

The order of presentation of these points is just based on the order in which he came to my mind...

In vb.net with visual studio, there is a visual line break between each method, property. For many people, it's not a good reason to prefer vb.net over c# but I don't understand why the c# team at Microsoft don't have implemented it. There is a add-in that draw this line in c# but thanx again Microsoft to have a c# team and visual basic team that don't talk to each other.

In vb.net, when you create a winform, you have two combobox in visual studio at the top of the editor and you can auto-generate event automatically when selecting an event on the right combobox. When you attach dozens of events each day, it can be very cumbersome to don't have this feature. With c#, you have a small button at the top of the property grid that can generate event but it's not fast as in vb.net. More, if you attach event of control in c# and delete the control on the form, the delegate created on the auto-generated code to handle event have to be deleted manually. Thank you again Microsoft.

In vb.net, when you try to modify a method that contain a linq query without modify the query itself, no problem but in c#, all the method code is locked. If you have a lots of linq queries or lambda expression, the edit and continue feature will rapidly be a good old thing. Ok, a little bit of exaggeration... but :)

In vb.net, when you create a method name and tap enter, the 'end sub' will be automatically created. In c#, do it yourself. Ok, if you have resharper or devexpress installed, it will be better but why all these little but greats features were not be implemented in c#.

In vb.net, when you have errors on your code, the errors are automatically displayed and when you correct it, these errors are removed of the stack in real time. In c#, you have to build your project to realize that you have successfully corrected or not the specified errors. Why c# team don't have put an option to verify in real time error like in vb.net. With big solution, no real time verification of error can be a very nice optimization of performance but I love to see a stack of error disapear while I correct it.

Like other person have mentionned, I think it's more easy to read vb.net condition if..end if, select case... end select but with devexpress painting bracket, forget what I said.

With vb.net, there are many many bugs in visual studio. Just to mention one in visual studio 2010, the intellisens don't filter correctly enumeration if you have the mode "common" activated instead of "all".

With vb.net, you are perceived as a dummy guy because statically, more bad programmers use vb.net instead of c# because c# is harder to learn and promote better programming practice.

Like other said, c# programmer have better chance to have a good job with more money.

In the head of customer, vb.net = guy who program in his basement with a bol of spaghetti of code. c# = wow, you are very intelligent. The fact is that it's not because you program in c#, that you make a good program but statically, yes.

With all these points, I chose to convert all my vb code in c#. I program with all the best practices of object oriented, design pattern, clean code with standards and strict syntaxe and I can program like that for 50 years but from the eyes of community, I'm not a good programmer. I will convert my code in c# with no other best practices and I will be another person; a great guy who you must respect..... :( what a joke...!!! but it's the reality.