A group blog from members of the VB team
As you can see in the VS2013 Preview, we have not added new language features to Visual Basic and C# in the next version of Visual Studio. I’d like to share our thinking on this. There are essentially two main reasons why we chose not to evolve the languages this time around.
The most important is that we just shipped new versions of these two languages less than a year ago, with support for asynchrony being a major new and impactful language feature in both. Developers are still learning how to integrate and benefit from the asynchrony shift in languages and APIs. We are very excited about the quicker pace of release for VS, but we believe from experience that language versions need a little more time to settle in. Our current thinking therefore is that Visual Basic and C# should stay closer to the pace they have been on for the past decade. It’s a balance between providing stability and new value, and we feel like we already have that balance about right.
There is a more tactical reason for us as well, which is that we are nearly done reimplementing the compilers and language services for Visual Basic and C# from the ground up. You may have heard of this effort as the Roslyn project, and there will be many end user benefits to this work when it ships. From our internal perspective on the language team, the new infrastructure makes it vastly easier to implement and test new language features with confidence, quality and great tooling. While the old compiler infrastructure is rock solid and supports VS 2013 beautifully, any effort we spend implementing new language features on it takes away from investing in the tooling, language features and compiler APIs that will power the future.
We are actively working on the next versions of Visual Basic and C#. The language design team is in full gear, led by Anders Hejlsberg as usual, and we are considering lots of new language features, big and small. We are looking very much forward to sharing more details about this work as the ideas mature, and to ultimately ship these new language features in a future version of Visual Studio.
In the meantime, do enjoy VS 2013, and not least the improved async debugging!
About the Author
Mads Torgersen is the program manager for the C# language design and specification, and is also on the VB and TypeScript language design teams.
This makes sense. I thought it was a little quick to have VS2012 released as our business has around 3 years before considering upgrading technologies, but getting VS2013 was a surprise
Does this mean you will put more resources in fixing the GUI?
Thanks for the update Mads - missed you at BUILD this year, but I'm looking forward to the next one - where hopefully Roslyn final is released!
Anders Hejlsberg told at BUILD 2013, that 'Roslyn compiler is done'. Do you plan to release it before VS 2014, where Roslyn will be fully implemented ?
This is very good news to know future functionality is still planned; there was a serious concern amongst developers that Anders had switched to TypeScript (or away from C# and VB anyway) and that C# had started to recede in importance much like WPF/Silverlight/etc. has done due to the apparent victory of the Windows teams over the .NET teams.
You write "new infrastructure makes it vastly easier to implement and test new language features". Does this mean we could use it to create new languages (new grammar/semantic/keywords), which 'somehow' derive from C#/VB or more abstract languages models ? I've heard so far that Roslyn will be only for analyse and manipulate program data (AST, etc).
Just say "Hey we're not quite done yet with Roslyn. It's a monster project and it has to be perfect. Hang tight and you'll be blown away by its sheer awesomeness, promise."
The 2nd paragraph is cringeworthy and didn't need to be written. The implication is that developers are too incompetent to absorb new changes rapidly. Agile is all about incrementalism, no good reason not to trust in your own innovation and cycle language changes through quickly and efficiently. Step...step...step...
Now the 3rd paragraph - about Roslyn - that's the heart of the issue, and in my view one that makes any changes to the language worth waiting for. Like, why mess with aging vbc and csc when Roslyn is, what, 12-18 months away? It also offers a clean break, er, excuse to make some compat changes to cast off some of the little goofy issues built up over the years.
So yeah...this post would have been a lot better without the sentiments of the 2nd paragraph. Excited as always for the next rev of VB and C#.
Great comments, all! I'll try to address the questions below.
@ThomasX: I told you what my team is putting more resources in - getting Roslyn to awesome. I can't answer for how the teams responsible for the GUI are prioritizing their efforts, but I know they take user feedback seriously into account, so please log your specific concerns on UserVoice to help them out. Thanks!
@Tristan: Exactly how and when we roll out the new infrastructure is still being worked out. First step is extensive internal dogfooding to ensure that quality, compat and perf are up to snuff. We're in the middle of setting up a broad internal roll-out, and the outcome will help determine our public plans.
@Tristan: Roslyn does not come with a language extensibility model. We can implement language features more easily because we're Microsoft and have the source code. :-)
@CraigAJohnson: Sorry if the second paragraph made you cringe. We hear feedback both ways on the language feature cadence, and the two sides balance out nicely, which is one reason we feel no need to mess with it at the moment. This may change. So far we have had some very big and impactful language features in each release. If we find ourselves focusing on smaller features at some point in the future, I can imagine us choosing to trickle them out more incrementally. For this specific moment in time, we are seeing our users incredibly excited with async, but also needing to put a lot of effort into making good and pervasive use of it. It is a singularly impactful feature with little prior art in the mainstream marketplace, and we all need time to learn and share the gotchas and best practices. We're in no rush to push the envelope on the language front while we help land the async experience.
No doubt Async/Await is a beautiful thing (though I think the F# folks have it nailed a little more cleanly than the TPL piggyback but it's wayyyy too late to change it now so make the best of it via guidance I guess). I dunno, this sort of feels like marketing double-down-speak to me :-) Why can't you make language advances - from pebbles to boulders - as quickly as you like so long as there is backwards compatibility? It doesn't make any reasonable sense to buy into some notion that language innovation has to be metered out from on high so that a few laggards can play catch up. That can take place quite nicely in conjunction with introducing new awesomeness, no? Even the BCL team is releasing on NuGet. Count me in as one who wants to push things forward, not hold back for lame artificial adoption-rate concerns. Your response persuades me even more that language development can and should become more agile, not less. Perhaps it's just a philosophical difference of opinion. Thanks for your time!
@CraigAJohnson: Seems like a great discussion to continue over a beverage sometime. :-)
Will Rolyn be able to parse/analyze old C# projects? I mean projects created with VS2010 for instance. Thanks.
I wish you guys would have more of the possible language feature discussions more publicly, maybe even record the conversations. It would be really interesting to see the arguments for and against certain features.
Also implement the idea of Mixins / Behavioral inheritance please. "I have a list of things, and they all need to have this behavior but are not the same thing."
Okay, The improved async debugging is a wonderfull thing and worth a new release.
Please keep us posted on new language features.
Thanks for this post!
Why to use .NET when you can use free and portable languages as Java or Mono?