Following is a summary of the session “The Future of C# and Visual Basic” presented by Anders Hejlsberg, lead architect of the C# programming language, in PDC 2010.
Before talking about the future, Anders starts with a review of C# and VB.NET history.
Anders identifies three major trends over the passing decade:
- Declarative – concentrates on “What do you want do?” instead of “How you want to do it?”
- Dynamic – allowing more fluent style of programming using dynamic languages like IronPyton.
- Concurrent – leveraging multi-core and multi-pc processing.
Note that for the rest of the talk Anders relates to C# only, but Visual Basic is paired with C# in all that matter.
When you take a look at the C# language constructs (not .NET Framework), there is nothing specific for concurrent programming other than a simple “lock” statement.
Well, this is going to change on the next version of c# with the addition of Asynchronous Programming to the language.
Today’s applications are increasingly connected to other services. This induce more latency, UI responsiveness problems and scalability issues.
Asynchrony in a Nutshell
On a synchronous operation you call a function and then wait for it to return the result.
On an asynchronous operation you call a function, give it an OnCompleted callback and continue to do other things. When the result is ready the OnCompleted callback is called.
So using asynchronous programming we gain:
- UI responsiveness: since the the UI thread is free do handle user interaction
- Server scalability: threads can be reused for other requests.
Presenting Visual Studio Async CTP
The Visual Studio Async CTP (Community Technical Preview) adds to C# two new keywords: await and async. These keywords use heavily the class Task<T> which was presented in .NET 4.0.
These keywords are used as syntactic sugar for making asynchronous programming easy. A good comparison is the the yield keyword which was introduced back in .NET 2.0 to allow easy implementation of iterators.
Task<T> is an ongoing operation that will eventually return a value of type T.
The await operator works on Task<T> instance and causes an asynchronous wait for the value of the task. Using the await operator can be done only in functions declared with the async operator.
The async modifier is used on a function declaration to indicate this is an asynchronous method.
This means that the function does some of its processing asynchronously.
The return value of an asynchronous method must be either void, Task or Task<T>.
Note: as a convention, the name of asynchronous methods that returns Task or Task<T> should end with “Async”. (e.g. GetDataAsync)
When you run an asynchronous method, it actually runs synchronously until the first encounter of await operator. At this time it returns control to the caller while asynchronously waiting for the remaining of the function.
In his talk Anders show how using the new keywords, handling errors is done by simply adding a try catch block, same as with synchronous method calls.
Why Not Use Multiple Threads?
Most of the problems asynchronous programming solves can also be solved using multi-threading, so why not?
The problem with multi-threading programming is that it brings to the table its own set of problems and overhead. Multi-threading demands that you handle synchronization to shared resources, which has we all know can be a pain.
In addition, multi-threading cause context-switching overhead.
So when should we use multi-threading?
Only on CPU-bound operations where you really need to use multiple CPUs to cut processing time.
Status of Compiler Services Project
Although no official announcements were made on this subject, Anders did show a demo that uses the current version of this project. In his demo he showed an extension to visual studio that uses the compiler services to copy code in C# to the clipboard and paste it as VB.NET code, the extension uses the compiler generated syntax tree for the code to do the conversion accurately.
That’s it for now,