NV: Could you clarify when to use await and when Task.Run?

EL: The two do very different things.

Task.Run means “here’s some code that does some high-latency work. Please immediately give me a Task which represents this work, so that this thread can continue to run normally.  At some point in the future, find an idle thread in the thread pool and execute the work on that thread. When the work is done, let the Task object you created know that fact.”

By contrast, await task means “I already have a task object which represents some high-latency work. This method is unable to do any more of its work until the high-latency work is complete. Therefore, return from this method immediately so that this thread can continue to do more work. At some time after the task is complete, resume execution of this method at the point where we left off.”

NV: Where does the Statemachine and the Synchronization context fit into it?

Both are mechanisms that work together to determine where and how a method which did an await gets resumed when the awaited task is completed.

When you use await in a C# method, the compiler transforms the code into a state machine, the details of which are a bit complicated to explain. Basically by a state machine we mean code where there is a number – the state of the machine – that says at what point in the code the method should be resumed at when the task is complete. This is an implementation detail of the compiler, and not something you typically have to worry about.

The synchronization context determines whether the method resumes on the same thread that it awaited on. For example, in a Windows Forms application we would expect that a method that awaited on the UI thread would resume on the UI thread. But if we awaited on a worker thread in a console application, it seems reasonable that the method could be resumed on any worker thread; after all, the one that actually did the awaiting might be busy doing something else when the task completes.

NV: What feature offered by another language do you envy the most and would like to see in C#?

EL: Ah, good question.
That's a tricky one because there are languages that have features that I love which actually, I don't think would work well in C#.
Take F# pattern matching for example. It's an awesome feature. In many ways it is superior to more traditional approaches for taking different actions on the basis of the form that some data takes.
But is there a good way to hammer on it so that it looks good in C#? I'm not sure that there is. It seems like it would look out of place.

So let me try to think of features that I admire in other languages but I think would work well in C#. I might not be able to narrow it down to just one.

Scala has a lot of nice features that I'd be happy to see in C#. Contravariant generic constraints, for example. In C# and Scala you can say "T, where T is Animal or more specific". But in Scala you can also say "T, where T is Giraffe or less specific". It doesn't come in handy that often but there are times when I've wanted it and it hasn't been there in C#.

There's a variation of C# called C-Omega that Microsoft Research worked on. A number of features were added to it that did not ever get moved into C# proper. One of my favorites was a yield foreach construct that would automatically generate good code to eliminate the performance problem with nested iterators. F# has that feature, now that I think of it. It's called yield! in F#, which I think is a very exciting way to write the feature!

I could go on for some time but let's stop listing features there.

NV: What about Traits ? Is it something that you like from Scala?  

EL: Any system that allows efficient code reuse without having to establish a sub-typing relationship, I think is worth looking into.
I find that C# programmers, and even more so C++ programmers, tend to over-use inheritance as their reuse mechanism.

NV: Is the next version of the language going to include major changes, breaking changes, or will it just be a 'polished' version of its predecessor? What can we expect ?

EL: Let me break that down into a couple of questions.

Will there be a C# 6.0? Yes, that's been announced.

Will there be breaking changes?
Microsoft tries very very hard to ensure that there are no breaking changes; legal C# 5 code should have the same semantics when compiled in C# 6. There likely will be a few corner cases where breaks occur, but hopefully these will not be in realistic code.

For example, something I faced all the time on the compiler team was

"in this obscure case we are allowing the program to compile, but the resulting program doesn't make any sense and according to the spec it should be an error".

In those unfortunate cases we would get a small committee together to argue out the likelihood of breaking any customer vs the value of getting the compiler correct. In a lot of those cases we kept the compiler technically wrong, just to avoid accidentally breaking someone who had a crazy program. The bar is pretty high for breaking changes.

NV:What will the feature set of C# 6.0 be?

EL:I am under NDA and cannot discuss it in details, so I will only discuss what Mads Torgersen has already disclosed in public. Mads did a "Future of C#" session in December of last year. He discussed eight or nine features that the C# language design team is strongly considering for C# 6.0. If you read that list carefully -- Wesner Moise has a list here

http://wesnerm.blogs.com/net_undocumented/2013/12/mads-on-c-60.html 

- you'll see that there is no "major headliner" feature.

I'll leave you to draw your own conclusions from that list.

Incidentally, I knew Wesner slightly in the 1990s. Among his many claims to fame is he invented the pivot table. Interesting guy.

NV: Java as tortured as it might be, revitalizes itself due to Linux and the popularity of mobile devices. Does .NET's and C#'s future depend on the successful adoption of Windows by the mobile devices ?

EL: That's a complicated question, as are all predictions of the future.

But by narrowly parsing your question and rephrasing it into an -- I hope -- equivalent form, I think it can be answered. For the future of technology X to depend on the success of technology Y means "we cannot conceive of a situation in which Y fails but X succeeds".

So, can we conceive of a situation in which the market does not strongly adopt Windows on mobile devices, but C# is adopted on mobile devices? Yes, absolutely we can conceive of such a situation.

Xamarin's whole business model is predicated on that conception. They've got C# code running on Android, so C# could continue to have a future on the mobile platform even if Windows does not get a lot of adoption.

Or, suppose both Microsoft fails to make headway on Windows on mobile and Xamarin fails to make headway on C# on Android, etc. Can we conceive of a world in which C# still has a future? Sure.

Mobile is an important part of the ecosystem, but it is far from the whole thing. There are lots of ways that C# could continue to thrive even if it is not heavily adopted as a language for mobile devices.

If the question is the more general question of "is C# going to thrive?" I strongly believe that it is. It is extremely well placed: a modern programming language with top-notch tools and a great design and implementation team.