An email concerning .NET Languages prompted this reply from me:
I used to be a heavy VB.NET basher. I've been reading a lot on this issue lately (Introduction to .NET languages, VS.NET and Extending VS.NET, It's the Runtime Stupid, and Sam Gentile's Blog in general, among many others), I've seen the light (or maybe the darkness, who knows which?), and I am officially reversing my previous position.
It doesn't matter how much any given language diverges, it all gets compiled to MSIL. In the end, it is all about the CLR, not the language. If you can program with the .NET Framework, you should be able to pick up the syntax to a language very easily, i.e. no more than a week to be productive. What was harder to everyone here: learning to use braces and semicolons, or learning to use (or even comprehend!) the vast reaches of the .NET Framework? If I consume or include a library application in my project, do I care what language it was written in?
Someone whom I work with was complaining about DotNetNuke, the open source portal program. He is using it for a web site he is creating. Even though he does not NEED to even touch the source code since the project is extensible through modules written in any .NET language, he was complaining that it was not in C#!!! Talk about looking a gift horse in the mouth!
As noted recently on .NET Weblogs by Roy Osherove, employers are still myopically requiring 2 years VB.NET. I applied to a job with this requirement and they turned me down because I had 2+ years C#! Do we (or should we even) have to explain that we have 2 years experience in .NET, and that the language does not matter? The author of the second response (below) has been reading a book recently, Essential .NET, Volume I: The Common Language Runtime, and it is an awesome book from what little I have seen online and in the bookstore. Anyway, I believe it is more important to study something like this book than it is to study a "pure" C# or VB.NET book.
Finally, in the grand scheme of things, using *any* .NET language is far better than using, say, Pascal, Assembly, or some other earlier-generation language.
The first response:
From what I've read about the future of C# as a language and the compiler enhancements it will get (e.g. generics, iterators, anonymous methods, etc.), I've also heard that VB.NET will get these as well (plus XML code commenting). If M$ would have kept these features exclusive to C#, then there would be more of a compelling reason to stay with C# . Either way, like you point out, you're going to end up with nearly identical MSIL code at compile time and, for the most part, the code will have little performance difference.
If you really want to get into truly advanced features and squeeze every last bit of power out of .NET, then you'd want to look at C++ and the managed extensions for .NET. Otherwise, in the grand scheme of things, it just doesn't matter one way or the other.
My recommendation for everyone is to tailor your resume to the job requirements. If they want two years VB.NET, say you have it. If they want two years C#, no problem. Just change the keywords as necessary (INFO: Differences Between Visual Basic .NET and Visual C# .NET). The only thing to be leery of if working in a VB.NET shop is that the developers tend to carry a *lot* of "baggage" from VB6 with them.
I agree completely. Part of the reason I initially championed C# over VB.NET is that having to rethink all of the syntax of a language induces you to rethink how you do everything in general. I think this helped my team a lot when we first moved to .NET. I see many hard-core VB6 programmers trying to do things the same way in .NET. This makes their adjustment so much more difficult. Things that used to be hard are easy. Things that used to be easy you can do a different way, which initially might seem difficult until you figure it out, and then it (usually) is as easy as before.
The second response:
Don Box’s Essential .Net, Volume 1: The Common Language Runtime book is really good and discusses the underpinnings of the .Net framework in a way that is much more interesting than some Wrox Press (or Wiley or whomever!) “How To Make An E-Buzzword Application” book. Don Box led much of Microsoft’s efforts to xml-enable DCOM . . . which eventually turned into the CLR. He has a big brain.