Editor's Note

Is C# the Only Language that Matters?

Is C# winning vs. VB.NET?

• By Patrick Meader
• 08/01/2005

The idea behind letting different languages plug into the .NET Framework was simple: Why learn a new language if you like the one you know, and it lets you get the job done? But the chinks in this approach appeared almost immediately.

First, the two Microsoft-authored languages were on a different plane than other languages. The corporate world trusted the languages from Microsoft more than others. This world is risk-averse, and these companies are not inclined to allow developers to use something they think might not be around two or three years from now.

Second, there is a significant difference in the perception of the two Microsoft-authored languages that dates back to the original .NET announcements. C# was new and exciting. Derived from C and developed by Anders Hejlsberg, C# seemed to have stolen the hearts of developers at Microsoft. New .NET code samples from Microsoft appeared first in C#, and some months later, after some prodding and pleading, in VB.NET. Sometimes. Microsoft heard these complaints, and you saw some adjustment in the amount of time it took something to be translated from C# to VB.NET. Significant code samples still appeared in C# first, but the time to translate it to VB.NET shortened over time.

Microsoft has made some progress on these points, but the damage was done. Developers saw this, and assumed that C# was first among equals, as these languages go. Developers also saw that C# developers earned more than VB.NET developers, even though the languages were nearly functionally equivalent. Even before the two languages shipped, you heard developers and pundits saying that C# was the only language that mattered.

Such pronouncements were premature. And still are.

Visual Basic .NET and C# were intended to fill different niches from the outset. Microsoft pitched C# as the managed language for developers who wanted higher speed and performance. VB.NET was the "productivity" language, picking up where VB6 left off, and letting you create solutions quickly and more easily. Unfortunately, these distinctions weren't really borne out in the initial implementations, which were functionally equivalent, with a couple exceptions. VB gained a lot from its incorporation into .NET. It became a viable tool for Web development, it inherited the .NET security model, and it let you create entire classes of applications that were previously not possible with VB6. It provided inheritance and other power-developer features that VB had always lacked.

That said, the effort in VB.NET 1.0 went into getting VB onto the .NET platform, and VB lost some of its character in the transition. When porting VB to the .NET platform, developers at Microsoft implemented several changes to make the programming experience in VB more consistent with the C# experience. Some features were lost, including deterministic finalization and edit-and-continue.

With Whidbey, you can see some separation in the languages. C# continues to mature in Whidbey, gaining generics and other performance and power features. VB.NET in Whidbey gets things a bit more on track with My.Classes, the return of edit-and-continue, and other productivity-related features, but the consensus among both readers and those who write for VSM is that it still comes up short from a productivity standpoint. The new changes just don't have the imagination and reach of earlier productivity enhancements introduced in VB. Edit-and-continue gets you back to where you were pre-.NET, and, while My.Classes are a significant new feature, you still can't go too far without having to fall back on knowledge of the underlying .NET Framework. That VB.NET in Whidbey comes up short is disappointing, but not surprising. It often takes Microsoft three versions to nail something.

I don't know how many more chances VB.NET gets from developers looking to build on what they had in VB6. My guess is one—the next version is make or break for this crowd. C# isn't the only .NET language that matters at this time, but it could be if the third time isn't the productivity and ease-of-use charm for VB.NET. Without such differentiation from C#—and whether VB.NET appeals to classic VB developers or not—there just isn't enough benefit to giving developers a C#-like language with VB-like syntax to justify maintaining both languages for .NET.