[Translation] I still haven't done F #

I think Microsoft is trying to sell us F # as something new and cool, but I have serious problems understanding the F # benefits in front of C #.


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

string Foo( int a, bool b)
{
//do stuff
}

void UseCurry()
{
Func< int , string > curriedFooWithTrue = a => Foo(a, true );

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

* This source code was highlighted with Source Code Highlighter .

F # can create pipelining (pipelining)!
C # also knows how.

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

* This source code was highlighted with Source Code Highlighter .

There are tuples in F #!
Sets are built into .NET 4 as a generic type (generic), so that 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 it?
Any "tail-recursive" algorithm can be implemented iteratively. But, of course, it is a nice syntactic sugar.

F # makes it easier to write asynchronous code.
This was one of the arguments on the F # demo at PDC 2008.
It showed how it was done using PLinq wrapped in a C # assembly. Maybe I didn’t understand some examples, but almost every example I’ve seen 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 having F # in a project will always outweigh the small advantages it can bring.

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

Does anyone have such an example?