Take the 2-minute tour ×

I really don't want to do VB.NET, but I need a job and I need a job fast. The two positions I am looking at both have existing apps in VB.NET, but are looking to convert them to C# and do new development in C#, but as well all know, sometimes this doesn't happen for a while and you get stuck with the main language. My background is in C# and after looking at VB.NET, my head is hurting. Any advice as I tackle a job like this. As I said, I preferably want stick with C#, but today, one may have no choice, so I have to just take what I get. I am looking for advice on this for those who have experienced it, are experiencing it, and those who have not.

share|improve this question

closed as off-topic by MichaelT, GlenH7, Dan Pichelman, Giorgio, Jim G. Sep 29 '13 at 14:11



There is no significant difference between VB.NET and C#, they're pretty much the same language. –  SK-logic Mar 17 '11 at 13:34
@Aaron, they're semantically similar, they're, essentially, the same language with slightly different syntax frontends. And a syntax is such an unimportant part of any language that it simply does not worth mentioning. –  SK-logic Mar 17 '11 at 13:48
@SK-logic That's like saying English and Spanish are semantically similar; grammar is irrelevant. Not sure I agree. –  Aaron McIver Mar 17 '11 at 14:37
@Aaron, exactly, that's what I mean - there is no learning curve. There is only an imaginary barrier, which any decent programmer should dismiss with no fear. It is important to understand that syntax in nothing. So many pointless holy wars about syntax, about the "only right" code formatting, and so on - all this useless crap should be dismissed once and for all, it have no relevance to programming at all. The sooner a programmer realise that, the better. –  SK-logic Mar 17 '11 at 15:56
@SK-Logic Agree with you completely about pointless holy wars around syntax, code formatting, etc... I understand your frustration in programmers stating they can only exist in one language, it's crippling behavior and should be avoided. I do still feel however that the barrier is real; I also believe it is minimal and not as confounded as many believe and should in no way be a reason to avoid transitioning into other languages. Good points..good debate... –  Aaron McIver Mar 17 '11 at 16:03
show 10 more comments

6 Answers

up vote 28 down vote accepted

C'mon its not that bad. Take it as an opportunity to learn something different.

more than 90% can be done via language translators (there are many online).

The rest is just syntax.

Don't limit your toolbox.


I'm fluent in both, and have worked on numerous projects in both languages. Including porting to C# and visa versa.

share|improve this answer
I totally agree. I am just afraid that it will take away from my C# skills if I am concentrating on VB.NET. What is the best language translator? –  Xaisoft Mar 17 '11 at 12:57
:) I can tell you with confidence that it will not take away your c# skills, in fact it will make you more marketable. There are many companies that have a mixed collections of projects in both languages. A developer who knows both is very attractive. –  Darknight Mar 17 '11 at 12:59
I tend to use converter.telerik.com –  Darknight Mar 17 '11 at 13:00
Are you working with VB.NET and C# on your job. If so, How is it? –  Xaisoft Mar 17 '11 at 13:01
+1: I went back and forth daily for a while, and I would start typing "dim myBlah..." and the C# intellisense would go, "huh?" and that's all it took to switch my brain back to VB.Net. Right now I'm maintaining legacy VB6 and writing new C# all day. No problems switching. –  Scott Whitlock Mar 17 '11 at 16:00
show 5 more comments

Although I prefer to use C# as well, do not make the mistake of thinking that, by somehow doing VB.Net, you are going to grow horns. :) VB.Net is a powerful, fully functional language and should not be considered as sub-par to C#. This is especially true w/ VB10 as many of the old annoyances are removed, such as line terminators.

In my current position, my main project is a VB.Net project though, before then, I was wholly a C# developer. There are some aspects that I miss about C#, mostly syntactical such as initializations for generics, lambdas, and multi-line strings, but I have never found myself 'held back' by VB. If nothing else, its a chance to quickly add another bullet to a resume and appear to be a more well-rounded developer. I think this is a good thing. When it comes down to it, it is less about the language preference and more about how you build your solutions.

share|improve this answer
add comment

If you have no choice, you have no choice. Try to use the new job to learn technologies you can use with C# as well.

share|improve this answer
add comment

If you really need a job fast, and that's all you have available, take it. It's a chance to learn a new language, meet more people, buy some time to look for other jobs, and fill in a gap of employment on your resume that you'd otherwise happen to have to explain to future employers. At the very least, you can focus on why it's not good to use VB.NET, and that's at least something.

In reality, it probably won't be as terrible as you think. and if it is, at least you're employed while you can keep looking for other work, and meeting people who might have a useful connection. Once I got my very first job out of college via a college recruiter (and that job was writing COBOL, in 2005, so I understand worrying about losing everything you've learned), every position I've had since has been because of the people I met at that job or through another professional network connection.

share|improve this answer
add comment

never too old to learn something new.

share|improve this answer
add comment

Don't worry about it. VB is essentially C#. It is worse in a couple places, and better in a couple places. The main pain you will experience is getting used to changes in the syntax, like types coming after names. Try to enjoy these benefits:

  • No ambiguity between user-defined equality and reference equality. The "=" comparison is always the user-defined operator. You use "is" for reference equality.
  • A more flexible equivalent to switch statements that doesn't require 'break' at the end of every case.
  • Default namespace and imports at the project level. No need to prefix every source file with 'imports System.Linq' and 'namespace Project'.
  • Ability to store anonymous functions with anonymous return types in a local. C# requires you to name the type of a function when storing it to a local, which means if it returns an anonymous type you just can't do it. VB doesn't have this limitation.
  • Impossible to create some misleading code that is possible almost everywhere in C# like "if (x) ; { y(); }" or "if (x = true) { y(); }"
  • 'dim x as new X()' syntax, allowing you to avoid typing the type of x twice when initializing it at declaration.
  • Implicit line breaks and line continuations. Much more convenient than using semi-colons.
  • Nicer array literals, when type inference is possible: "{1,2,3}" instead of "new[] {1,2,3}"
  • XML literals
  • "handles" event syntax. Makes it trivial to see what's wired up inside of windows forms.
  • "implements" interface syntax. More flexible than C#'s implicit by-name interface implementation.
  • A significantly better background compiler. You don't have to manually build to see errors like "interface member not implemented"
  • Ability to omit "select" clause from a linq expression, which is nice in filtering expressions like "from e in c where e isnot nothing" and ones returning anonymous types like "from e1 in c1 from e2 in c2" (enumerates all pairs).
  • (Coming in next version) anonymous iterator functions. Especially useful for cleanly separating eagerly-evaluated preconditions from lazily-evaluated iteration.

Not to say that C# doesn't have it's own advantages. Its syntax is generally more concise, it has unsafe and unchecked blocks, it doesn't have nearly as much legacy garbage like "On Error Resume Next", and it doesn't use the same keyword to represent either "default(T)" or "null" based on context.

share|improve this answer
add comment
