[Translation] I still have not cut through F #

I think Microsoft is trying to sell us F # as something new and cool, but I have serious problems understanding F #'s advantages over C #.


But F # can do curring functions!
Well, C # can do it too.

string Foo(int a, bool b)
{
  //do stuff
}
  
void UseCurry()
{
 Func curriedFooWithTrue = a => Foo(a,true);

 //invoke curried function.
 var res = curriedFooWithTrue(123);
}

* This source code was highlighted with Source Code Highlighter.

F # knows how to create pipelining!
C # also knows how.

var listOfInts = new List {1,2,3,4,5,6};
Func squared = x => x*x;
var squaredListOfInts = listOfInts.Select(x => squared).ToList();

* This source code was highlighted with Source Code Highlighter.

F # has tuples!
Kits are built into .NET 4 as a generic type, so they are available in all .NET languages ​​that support generic types.

F # has tail recursion.
Well, you caught me, she is there.
But tell me, when was the last time you really needed her?
Any tail-recursive algorithm can be implemented iteratively. But, of course, this is a nice syntactic sugar.

In F #, it is easier to write asynchronous code.
This was one of the arguments for the F # demo at PDC 2008.
It showed how this was done using PLinq wrapped in a C # assembly. Maybe I did not understand some examples, but almost every example that I saw can be implemented in C # with approximately the same amount of code.

What I would like to see is a really good example in F # that would be difficult or impossible to repeat in C #.
If F # is only slightly better than C # in some tasks, then the cost of F # appearing in a project will always outweigh the small advantages it can bring.

Another argument of F # is that it aims at a completely different range of tasks. Well, show us where F # shines, without cheating on what C # can or cannot do.

Does anyone have such an example?