# Visual Basic > Slow Chat with the Microsoft Visual Basic team >  Future of VB

## kleinma

There is a pattern we have seen emerge over the past couple years at Microsoft regarding .NET platform languages.

While the .NET framework supports many languages, it is clear the dominant players are C#, VB, and C++

C# and VB are very similar with respects to how development is actually done, while C++ is still pretty different as it has always been.


While there are only a handful of things that you can say VB does that C# doesn't and vice versa, more and more things are catering to the C# group, while VB gets left in the dust.

A few things that come to mind are

XNA Framework
.NET Microframework
MS Surface
SDK examples (Home Server, healthvault, WPF, etc..)

The list could be a bit longer but you get the point  :Wink:  


So where does that leave VB in terms of its future, and the future for us developers who love and use this language over C# because we like the language syntax better?

It almost does seem a little silly for Microsoft to support 2 programming languages that are *almost* identical in features, while they have to maintain 2 teams to support the languages, 2 sets of docs, 2 (which often leads to 1, C#) sets of samples to showcase technologies, etc...

The reason I write in VB is because I love VB, I love its syntax, and its readability. I am not a fan of semicolons and curly braces.

So when the tradeoff comes my personal preference on syntax, over the ability to get samples from MS in the language I develop in, or getting the ability to tap into other frameworks like XNA, C# starts to get a bit more tempting.

How can the VB team prevent a mass migration of VB developers over to C# if Microsoft seems to favor C# in so many areas of development, or do you feel it is important to have equal competency in both languages?

Everyone keeps saying "right tool for the job is what you should use" but C# seems like a swiss army knife to VBs can opener...

----------


## techgnome

And yet, despite that, VB is alive and kicking. You can read Patrick Meader's recent editorial on this ( http://visualstudiomagazine.com/colu...torialsid=2333 - VSM, Oct 2007 Vol. 17 #11). 

I think the reason C# seems to get the attention, is that it is truly a new language, while VB is _still_ thought of as a "toy" language. If that were the case, then VB.NET is the biggest, baddest, meanest Erector set I've ever played with. That would make C# a smelting & Iron works plant.

some one correct me if the following perception is off... I suspect that XNA gets the C# nod because most game developers are C developers in the first place. So it makes sense from that perspective to make it C# ready.

SDk/MSDN examples, I heard somewhere that C# is the internal language of choice at Microsoft (understandably - goes back to the "Not only am I the president of Hair For Men Club, but I'm also a member" credibility). As a result, the examples are done in C#, and later converted to VB. Not that I've had a problem with that, as reading it in C# and having to convert it to VB myself, gives me a better understanding of the code that I'm using. 

But that's just my perspective and experience.

-tg

----------


## kleinma

> some one correct me if the following perception is off... I suspect that XNA gets the C# nod because most game developers are C developers in the first place. So it makes sense from that perspective to make it C# ready.
> 
> 
> -tg


I actually believe that there is a limitation on the VB languages requirement for specific VB runtime files that C# does not require, which makes XNA development C# only. Perhaps someone from MS will clarify this.

I do agree with you TG that VB is alive and well right now, however it seems that C# is MORE alive, and, well, MORE well for lack of better terms  :Wink: 

I am just interested to hear the VB teams take on this whole thing, since they work at Microsoft, they might be able to shed some light on how this looks internally, since I only have an external view

----------


## Merrion

The VB team should publicise some of the things that VB.Net 2008 does that are light-years ahead of C# --- importing xml namespaces using the Imports statement and XML literals.

----------


## PaulYuk_MS

Hi -

Good feedback everyone.  

There's a couple issues being discussed here related to the future:  content parity (availability of VB content) and momentum.  I talk about feature differences in another post.  

In terms of momentum, there is no question in my mind that the future is bright for VB.  VB is the most used .NET language according to the internal surveys we conduct as well as Forrester research (both looking at pro developers).  Then there's the fact that VB is hands down the most downloaded and registered Express Edition (includes pro's and nonpros).  The VS Mag survey is a data point but but it's pretty different than our findings -- we hoped to have more time to review and reply to the editors...   Here is Paul Vick's post with more specific numbers:
http://www.panopticoncentral.net/arc.../01/22453.aspx


One insight is C# has a bit of the early adopter phenominon; more early adopters appear to be C# developers  -- we try to be conscious of when we're seeing the early adopter skew vs. the mainstream developer usage.  

In terms of content, our team prioritizes broad reach content and mainstream scenarios.  You point out the top of mind cases where MS came out with C# first -- this has to do with a mix of reasons from it being audience appropriate for C programmers, technical reasons in the way, and some of our own C-shop body language showing through (a problem we want to solve).  The first two examples (on your content list) are cases where a custom version of the .NET framework was created.  Our runtime agility work in '08 will make it technically possible & easier for VB and other MS teams to easily get VB support in those new frameworks.  We're partnering with them to see when we can have VB be a mainline option.  Surface, while extremely cool, is targeting a very specific audience and we've heard more interest from the c/embedded crowd.  As these technologies get more mainstream we'll see them adding VB support so they can tap into a broader audience.  Regarding the SDKs - I'm not clear on the issue.  We see roughly parity here, but I might be missing some specific cases.

Let's look at the counter examples for a moment.  ASP.NET and Windows Forms are two of the most mainstream technologies you can think off.  We have language parity in all broad reach content, not to mention, all the super how to videos are shot exclusively in VB.  Check out these sites:
www.asp.net
www.windowsforms.net

Joe Stagner has a good post on why he chose VB. Check it out.
http://blogs.msdn.com/joestagner/arc...ual-basic.aspx

We'll continue to push on our content coming out in VB, keeping in mind we'll prioritize mainstream technologies over cutting edge.  We'd always love your feedback on what content VB developers need sooner than later.  Also, as always there is an opportunity for folks in the community to step in and nail VB content in the cutting edge areas.  

Best,
Paul

----------


## Liquid Metal

Excellent questions kleinma and very well written.

Over the years, we have converted many Java developers into .Net developers by transitioning them over to C#.

----------


## visualAd

I have not been using VS 2005 long and have used a mixture of C# and VB. Having come from both a VB and Java/PHP background; I hope that both VB and C# will be around for a long time because they both have their strengths and, the VS IDE is a dream to use.

One concern however about VB in the web development arena and one often demonstrated in PHP is the lack of attention to security among beginners when creating web applications. Some of the safeguards built into the framework prevent the more common attacks but I do however believe that RAD languages can pose a danger when mixed with web development. Beginners and those new to web development should be well versed on the risks of creating web front ends, especially in a business environment before embarking.

----------


## timeshifter

Quite a few security issues can be handled by the server hosting the web application. Outside of that, it is certainly best to know where access is allowed and what else can be gained with that access. Cryptography is a necessity when dealing with sensitive information, and the respective class doesn't make it overly easy to meet industrial encryption requirements. Possible, but not the kind of thing you'd do just because. If 2008 made some of those functions a bit easier to play with, it might encourage more security among websites.

----------

