>the await is not only suger and you can't just switch to something like Async.await(foo), because just like the iterators it's compiled into a state machine

Yes, but a reentrant state-machine is not the only implementation that could have been chosen -- other implementations could have been suppplied in library form only, with perhaps after a few competing implementations leading to eventual compiler support, with tooling support there first via IDE plugins. For exampe, consider as input to the async runner a new [] {...list of lambdas...} or for more flexibility as in F#, a lambda that returns the next continuation, etc -- with not much more effort than went into writing a custom state-machine via new keywords, the C# equivelent of builder/computation expressions or type-safe macros could have been supplied to provide a more general solution to expressing asyncs, with the additional benefit of allowing varying implementations of asyncs and providing a mechanism to describe other higher-order constructs. (Though I understand they had the convenience of reusing some of the state-machine code for iterators.)

Again, a good example is events -- events generate boilerplate code with special scope semantics that are rarely used because GUI <i>frameworks<i> are actually what supply event and command semantics (perhaps bypassing events all-together and using interfaces or delgates) to real-world applications.

Hi,

the await is not only suger and you can't just switch to something like Async.await(foo), because just like the iterators it's compiled into a state machine, so that you can use it inside loops and other stuff and it creates the right continuations for you - this is the real power and we don't really get this with F# in this way.

If you did see the paper from D. Syme and T. Petricek (Joinads): this is something to look forward to (I really like the *match*)

It's done using a different mechanism in F#, but computation expressions support performing computations from within loops as long as the builder exposes For and While methods. The AsyncBuilder class supports these, so the end result for the programmer is pretty comparable when doing async programming in C# and F# (modulo hot/cold start and other conceptual issues).

@Stephan: Indeed, there are plenty of other cool features in F# that will make it my language of choice for my next project in scientific or technical programming. I was an instant fan of F#'s syntax and want to explore it some more.

I guess async programming is only one approach to parallelism. Don's blog post hints at a bright future for async now that C#/VB are on board. Interoperability can now take on a high priority.

Well he asked about concurrent / parallel so one of the big things with this kind of apps is:

If you data doesn't change you can forget a lot of the problems you are facing.

But making non-changing data types in C# is not impossible but the design-patterns and feel of OOP makes it hard. And you can't get either the compiler nor the runtime to enforce this for you (which is true for F# too, and a shame)

In F# everything is inmutable by default and you have to make things mutable explicit or use some mutable CLR-type to work around this barrier. And of course the design of a F# solution should embrace functional programming aspects which lends to working with inmutable data.

Tail recursion is a feature of the CLR that got included for the sake of F# (I don't think that the other compilers produce tail-recursive code).

Lets say you have a function and the very last thing it does is calling itself (just to explain it with an easy example). In C# or VB or whatever the compiler will do the usual - push the env. on the stack, call the method, etc. - so with deep recursion the stack will overflow quite easy.

If you have tail recursion on the CLR "knows" that you never will need the thinks on the stack again, because just after the nested method call your function will return. So after all you end up with some kind of loop instead of a nested method call and you don't overflow the stack.

It's a technique every FP language needs in order to be useable in real life.

I hope this helps (it's somewhat hard for me to explain such stuff because I'm no native english speaker as you will have noticed by now)