What Are The Advantages/Disadvantages of Using Both VB.Net and C# In The Workplace?

Question

At a colleague's workplace, a decision is trying to be made about whether to use both languages in the workplace or to standardize on one? There are some VB.Net developers and some C# developers.

What advantages or disadvantages would there be to using both or to using one?

Edit: To clarify this question, the question is not asking the advantages of one over the other, rather what are the advantages/disadvantage of standardizing on both languages versus standardizing on one.

For instance, one point could be that C#/VB.Net may have more third party tools available and hence it may make sense to standardize all developers on that language.

Answer 1

This is personal experience mixed with workplace lore:

1. VB.NET is capable of being little more nimble, compared to C#, because there isn't a standards committee (except for any that may exist at Microsoft).
2. Most of the Google-able code hackery out there is done in C#, and most of the best resource books provide code samples in C# only.
3. VB.NET is tainted with a history of VB being accessible to even the most incapable of developers. This is unfair, imho, because VB.NET is much more a "real" language. But the taint isn't going to be washed away any time soon, and "real" programmers still generally despise it.

As for real life - I code in my own time in C# and VB.NET at work. I believe that because so much of the code one writes for .NET is calls against the framework objects, the differences are actually quite small. If you can declare variables in both languages you're 80% to being portable. If you understand the framework, the syntax of the languages is a small obstacle.

EDIT to directly answer your question: We happily use both (though mainly VB.NET) and haven't ever had any problems. We use Visual Studio which allows us to pretty freely mix code files/assemblies. I would encourage you not to limit to a single language - I think some diversity is good for the brain.

Answer 2

C# and VB.net are the same with a different syntax. You can convert from C# to VB.net and back very easily. VB.net does have a few extra advantages that C# does not, such as inline XML.

Most places have C# because its the more popular language.

Answer 3

I'd say given that there are "some VB.NET developers and some C# developers," there really is very little benefit to forcing everyone to use one language. Frankly even a VB.NET developer who's never looked at C# should be able to read C# code with no more than a brief introduction to the syntax, assuming he/she has a reasonable understanding of the .NET framework; and a C# developer should be able to do the same with VB.NET.

(I should also add: this is assuming everyone has access to a development environment in which the .NET languages can co-exist harmoniously -- e.g., VS2005, VS2008, etc., as opposed to one of the Express Editions, which as far as I know don't allow multi-language solutions.)

Answer 4

We should probably put on our Reality Glasses for this discussion. It's not just Syntactic Sugar going on here.

You will find that you can write code very quickly in Visual Basic.NET. That is largely due to some features that it has that C# does not yet provide: namely, the My namespace, which provides a plethora of functionality that C# developers have to frequently code by hand. (And that's a damned shame, if you ask me.)

I code in both languages every day. Coding event handlers for forms in Visual Basic is a snap, and it's VERY obvious what methods handle which events. It's not always as clear in C#. On the other hand, you can't always be as explicit in Visual Basic as you want to be, because Visual Basic does so much of the work for you. C# has the advantage of just getting the heck out of your way, and letting you get down to the nuts and bolts. Quite often, that's extremely liberating.

VB will let you invoke static/shared methods on an object instance. C# won't. You'll learn that the hard way when you try to port your code. C# will complain about unreachable code; VB doesn't care one way or the other.

But under the hood, when you get right down to it, it's all .NET. It all compiles down to MSIL. There will be minor differences. Visual Basic, for example, doesn't care about the case-sensitivity of names, where C# does. And the big gotcha there is that the CLR does as well. You'll realize that when you try to use reflection. Does that mean you shouldn't use VB? Nope. Just make sure you case things consistently -- especially your namespaces. (Namespace "My" and namespace "my" are two completely different namespaces to C# and the CLR, but they're the same to VB.)

Choose the language that makes you most productive, that reduces ramp-up time and maintenance costs. You may find that that means working with both languages. (We do!)

EDIT TO ADDRESS OP'S EDIT:

• Refactoring tools are available for both languages.

• Automated unit testing tools are equally applicable.

• 3rd party controls are going to be available for both languages because they're compiled down to MSIL.

• Now, for IDE productivity tools, the one thing that C# has at this time that VB doesn't is StyleCop. That may change soon (and I hope it does), but I don't view it as a roadblock by any stretch of the imagination.

Answer 5

After tracking your question for a little bit and noting your edit, I have to wonder if you're fishing a little bit...

Either way, I think it's fairly obvious that at least the latest third-party tools favor C#. I, like the other responders, code VB for work and prefer C# for other development. I have definitely noticed that the documentation for many third-party addins/plugins and in some cases the products themselves favor C#. ReSharper, even though 4.5 has better VB support, is still vastly more comprehensive when using C#. And other frameworks, like Fluent NHibernate, don't support VB at all. So for tooling, especially when considering late-breaking stuff, I believe that C# wins. Not to mention the fact that C# got a few new features in 3.0 that won't be available until VB 10 makes a wide release.

I still agree whole-heartedly with the others; if you can do it in C#, you can do it in VB. It's all the same CLR, in the end.

Answer 6

My workplace had traditionally been a VB.Net shop, but a decision was made a couple years ago to switch to C#. This happened mostly because the VB developers had either left or moved into other positions and most of the new hires preferred C#. We still have a large legacy VB.Net code base, but all new development is being done in C#.

I don't think there's a strong technical reason to choose one language over the other, as they are pretty equivalent in functionality, but I do feel there are some valid reasons to choose one type of developer over the other. While I believe VB and C# are equal, there's is the unfortunate perception that C# developers are better than VB developers. While there is some justification for this, it's overblown. (It was more applicable in the C++/VB days.) That said, the perception exists. This does cause some talented developers to avoid and bash VB (though they usually do so from ignorance). I do think it's harder to hire developers into a VB shop than visa versa, because a C# developer will often balk at the idea of having to use VB, but VB developers usually aren't as opposed to using C#. There is one significant disadvantage to choosing C# over VB and that's that C# developers generally get paid more.

In my experience, the best developers welcome using both languages. The more languages you know, the better.

Answer 7

I started out as a VB developer so naturally I migrated to VB.Net when I first worked with .Net. In fact my first .Net application was made in VB.Net too. But I tried out C# and found myself liking it better in a matter of weeks.

So I made some of that app in C# (some libraries) and it didn't hurt me. Now though I hate going back to the older VB.Net code and working on it. I really wish I could change it all to C# somehow.

That's not going to happen.

So what I am telling you here is, irrelevant of what language you choose (VB/C#) stick to it. Don't do mixed language development unless you have a compelling reason I can't think of yet :)

Answer 8

The few things I could think of:

Pros: 1. The ability to hire both VB.NET & C# developers. 2. Provides better cross language learning for developers.

Cons: 1. Requires some partitioning of code. 2. There a few language interactions to watch for.

I would prefer this route...

Answer 9

The advantage of standardizing on a single language is that basically everyone will have 1/2 as much to learn. I think it's better to spend the time learning more features of .NET, within a single language, rather than learning 1/2 the features in both.

As far as hiring goes, it does not really restrict you as a good VB or C# programmer should be able to switch to the other language without difficulty (or else they aren't really a good programmer :)

Answer 10

Don't fall for the "most examples / books are written for C#". Working out how to apply a C# example to VB.NET is trivial -- you'll have more trouble trying to understand what the moron who wrote the example / book is trying to do and what their hideous coding (un)convention is all about than you will mentally flipping C# syntax to VB syntax.

Also I'd say don't worry about whether you hire C# or VB.NET programmers: if they are any good at all then they won't have a problem with reading / writing both languages.

We use both here, and after a little resistance from some (we were using C++ before) have settled down fine. As I had predicted, the hardest thing for our team was (and probably still is) the conversion from MFC to .NET, not the language used to access the libraries.

FWIW our main split is VB.NET for UI code, and C# for backend / database / computation code.