Windows 8 App Store Screens Leaked

I disagree. I would say the opposite: That F# is a better language because it can access the rich set of libraries that already exist in the .NET ecosystem. You seem to think that's a bad thing. I don't think many would agree with that.

I think it's certainly innovative to have created a functional, static type-inference based language that can sit on top of the .NET runtime as a first-class citizen.

Building a library is not innovative in and of itself, and there is nothing in linq's concepts or execution which is novel or innovative.

Incidentally, LINQ is not 'just' a library. It can translate code written in a higher level language by examining the expression-tree that the code compiles down to. This is sort-of a poor man's lisp macros built into a statically typed language.

Ocaml has functors and modules and polymorphic variants and compiles to very fast native code. F# has more libraries, units of measure, and better support for parallelism. What is innovative about F#? Getting proper generics on a runtime like .NET is not something to scoff at. F# was one of the first languages to support view patterns - pattern matching on objects. Balancing OOP with functional, as well as very smooth interop with .NET is its own accomplishment. Leveraging a language that balances FP and OOP well will lead to a powerful style of language that simply is not well explored at the moment. Scala is another one with this feature.

Actors, First Class events and async can have you write code that is either parallel, reactive, concurrent or asynchronous easily. Workflows (monads) are also innovative and with inlining you can write succinct code that is faster than C# in certain cases.

As someone who is using F# to write some machine learning code (as well as thinking about approaching genetic programming, something dead easy in F#, with category theory in mind) its future plans on typed datasets in the language are intriguing.

As for Linq its innovation is that it is a generalization of list comprehensions. Here is what Erik Meijer has to say:

"A lot of people, when they hear LINQ, they even think about "It's something that has to do with SQL and databases". I don't think people realize that any type that implements these sequence operators you can write queries over, like in Haskell, as long as you are going to implement the monads type class - you can do binds, return and so on. All that's comprehension and it's exactly the same here. It will just take a little time before people have discovered that and they will write the most crazy LINQ implementations.

These things take time and I think it's good that they can get used to it in its current shape for lists or for collections that they understand. They will go on and do state monads and exception monads - I don't what - because if you look at the sequence operators, they are the monadic operators. What is also interesting is that, besides "select from" and "where" we also have "group by" and "order by", which are not in Haskell's comprehensions. Then the funny thing is what happened is that the Haskell guys saw that and said "That's quite useful". Simon Peyton-Jones and Phil Wadler wrote a paper where they improved the Haskell comprehensions with things from LINQ, so it is a nice circle going on where the languages influence each other and get better."