VB.NET vs. C#.NET?

Question

The company I work for has all of its legacy ("legacy" being used rather liberally in this context) code in VB.NET. They have about 6000+ lines of VB.NET code, so all of the developers are comfortable with it.

We have started to develop a new product, and are finding that some modules are easier to complete in C# than in VB.NET, such as Interprocess Communication via WCF.

The things our product will eventually need to do are as follows:

• Communicate via IPC between Windows Services, Silverlight, and WinForms
• Handle parallization, and all the complexity that comes along with it
• Windows Service and WinForms development
• ASP.NET, AJAX, and Silverlight development
• Database (SQL) access
• Lots of event handling (Sync and Async events)

My question is: Given the type of work we will be doing to complete our product, are there features of one language that will make life easier that the other does not have? And if so, it is worth asking the developers to switch to a language they are less comfortable with?

I was hoping to keep this as objective as possible, by listing exactly what type of work we will be doing with the product. Please don't turn this into a VB/C# holy war.

Answer 1

as Far as I know, you can do kinda' hybrid projects, but doing this (I Believe) will make people's life harder...

Answer 2

The differences between VB and C# are shrinking. (VB will soon have anonymous methods and multi-statement lambdas. C# now has background compilation, soon optional parameters, etc.) The practical differences in VS 2010 will be:

• VB has XML Literals, which are great. If XML tends to be a part of their rendering, that's a plus for VB. If you're sticking with ASP.NET forms though, this is less likely to make a difference.
• There is still a small set of features that C# will have that VB doesn't. Very small. An example is the Yield keyword, very handy for specific situations but something many will not notice.

Other than that, it's just the old VB v. C# question. A matter of taste for terse or verbose. (I slightly prefer VB because I love XML literals; if not for that I'd slightly prefer C# due to more online examples and slight syntax preference.) Since your team is already experienced in VB, that will probably make the difference. Kathleen Dollard has a great presentation on the difference between C# and VB.Net: Part 1 & Part 2.

Answer 3

You should go with what you know. If they know VB.Net (much better than C# that is) that will ultimately be the easiest route to take. There are differences between VB.Net and C#.Net, but for the most part they can accomplish the same tasks. Switching languages takes a lot of time, because you first have to learn the language, and then you have to work with enough to be able notice the tiny gotchas that are different between them.

Answer 4

Given that the idea behind the .NET platform is interoperability between the languages (AKA, you're not tied to one language), if you are finding development easier in C#, and the rest of the team agrees, I would say work on the other components in C#. But, overall, VB.NET and C# can accomplish the same tasks. One thing to think about - is the reason the C# work going faster/easier because you understand it? If the rest of the team doesn't understand C#, but knows VB.NET, that will most likely take precedence.

If you're looking for a comparison of VB.NET and C#, follow the link. If you truly want to use C#, then I would recommend coming up with how you think it will make development faster (metrics and numbers are good, too) and go to your team with that information.

Answer 5

People who learn vb.net also need to to know c#.net also because almost every example you'll find online will be in c#.

Answer 6

VB.NET will make your life easier in the short term but much more difficult in the long term. VB.NET allows you to do non-OOP programming too easily even with the Strict/Explicit On. One example: Modules that mask as static classes but actually allow an incredible level of global access to its "members."

You might also notice that C# is being favored more and more in .NET as the platform matures. It's entirely possible that in a few years it will be very difficult to get support for your VB.NET issues and even harder to find new engineers who know the language.

Answer 7

Visual Basic and C# are, for the most part, dialects of each other. C# tends to be the second to get new language features, since Microsoft has full control over Visual Basic but is trying to make C# more comfortable for programmers who come from C++ or Java backgrounds. I have a strong personal preference for C#, but it's just that- a preference.

Anything that interacts with native code is going to be much easier in C# than Visual Basic simply because C# has syntax for native memory management that Visual Basic really doesn't have the same support for (related is the "unsafe{}" block in C#). But nothing you've listed here needs that- 100% of this is standard .NET library stuff, with a healthy whipped-cream topping of Linq for the SQL work.

That means this project comes down to personal preference. If your team has more experience with Visual Basic, that makes Visual Basic probably the correct tool to use.

Answer 8

For your application, and depending on its complexity, it may be worth writing a small module in both languages. This would allow you to become familiar with C# and also compare readability and efficiency in regards to what you are trying to accomplish. I myself love to learn new languages so I would even do it in my spare time.....that is if I had any :/

Answer 9

To me the difference is not so much in the languages themselves. I use both frequently and from time to time I miss the other language's features.

The difference starts when you use framwork tools like DI, ORM, mocking etc. Most tools seem to have a strong focus on C# for syntax,documentation and examples. I assume the tools are used by many VB programmers as well but they don't seem to be very visible on blogs, discussiongroups etc.