C# and VB.NET vNext

Posted by Patrick Smacchia on October 29, 2010

Yesterday Anders Hejlsberg presented The Future of C# and VB.NET at PDC 2010, see the session on the official site here.

Two third of the session was dedicated to a new C# language enhancement: support for asynchrony. A CTP is available. So basically two new C# keywords appears, async and await, and this will make possible to transform typical synchronous code in asynchronous code just by adding these two keywords at the right level. Semantically synchronous code like:

  • download these pieces of data, wait, process these pieces of data, wait, store the results, wait,…

will be transformed to asynchronous code like:

  • download these pieces of data and then once downloaded, process these pieces of data, and then once processed, store the results, and then once stored…

So basically, these 2 new keywords will transform typical imperative code (do this, then do that) into declarative code (do this and then once you’re done do that). The ultimate intentions behind declarative asynchrous programming is to use efficiently resources (multi-core processor, threads, network, I/O…). Under the hood, the C# and VB.NET compilers will perform complex transformation on your code that would make a sailor blush! The beauty is that, today, to get asynchronous code working, it is the developer burden to code these complex transformations.

On a side remark, these complex transformations are comparable to what the C# compiler is already doing to get iterators and closures working. See the Eric Lippert recent 5 posts series on Continuation Passing Style beginning here. And see the yesterday’s post of Eric on Asynchrony in C# 5 Part One for more details on wait and async new keywords.See also the Jon Skeet post Initial thoughts on C# 5′s async support that demystifies a bit what’s happening under the hood. Btw, I am a bit proud to have anticipate the power of continuations five years ago in an article on C#2 published in Feb 2005 [:)] (see Iterators with C#2 where I use continuations to compute prime numbers).

Anders promised that wait+async is the first step of many numerous future steps on handling concurrent programming at the language level. See the official website Asynchronous Programming for C# and Visual Basic.

 

Finally Anders closed its talk on the Compiler As Service state. Clearly, while wait+async is a very elegant addition of C#, Compiler As Service will be the killer features of C# and VB.NET vNext. I already talked about Compiler As Service in C# 5 and Meta-Programming. What Anders revealed yesterday is that a public fine-grained API will be made available to tweak the work of the compiler in any way you can think of. The number of groundbreaking technologies and tools that can potentially be built upon such a powerful API is outstanding. It is hard to forecast all the implications this will have in the next decade. Anders just shows how easy it is to code a C# to VB.NET convertor, but soon, building complex refactoring tools, developing your own AOP framework or editing your own DSL that inherits some of the C# syntax will be made easy. We now have an explanation why MS neglected until now things like refactoring in VS or AOP: it was because they wanted to build a more ambitious project at lower level. Today we know, this project is Compiler As Service.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • guest

    About what interview are you walking?

  • RichB

    @Dmitri Yes – it was amusing that Anders’ answer was in response to a question from @postsharp.

    Another thing he said in that interview was the compiler as a service work is for both VB and C#. Currently, both compilers are written in C++ (wonder what happened to the VB X (VB 10) compiler that was being written in VB….). He said that the compiler as a service was now a managed implementation.

    Now, it’s well known that the C# team implement a prototype, show it at a PDC, then throw it away and start the proper implementation.

    The async prototype apparently shares 99% of code between VB & C# – so it must use a common AST between VB and C# to perform the complex transformations. If VB and C# up until now have used separate, different compilers with different ASTs, then which AST is the async prototype working on? The new Compiler as a Service managed AST?

  • http://devtalk.net Dmitri Nesteruk

    Actually, the bit about AOP in the interview surprised me: it was almost as if Anders was saying that AOP would be impossible in C#vNext, which I certainly hope is *not* the case. But I think he was hinting at the fact that AOP won’t be *easy* (an won’t be available out-of-the-box). Which, at least for me, is very confusing because we have already seen that AOP in languages that do support metaprogramming (e.g., Boo) is actually very easy.