That said, I have a few concerns before actually being sold to F#.
1. F# must interact with the remaining of the .NET ecosystem. So, I think F# may have some interoperability features to ease the process. Wouldn't that increase the complexity of the language? This is a similar concern when I evaluate Scala as an alternative to Haskell. The feature set of Scala looks a bit messy to me, nearly on a par with C++. It could be OK if I use only the "functional" subset of the language. But does it really make me free from e.g. null pointer dereferences?
2. Do F# guys actually develop their "native" libraries not relying on the .NET ones? This is similar to #1 but slightly different. I think if the two languages are somewhat similar, and even share the ecosystem, there may arise a tendency to make libraries that work on both languages. But if one makes a C#-focused library it must not be very easy to use in F#. Is this not a concern in the F# community?
What I find more confusing is C#'s love of mutation. For instance, "fluent" interfaces, where you call an object's method and it returns the same object. I find it confusing in C#, and it seems even more out of place in F#.
F# feels less complex than C# - less "axioms". I've not evaluated this even remotely formally, but it's the feeling I have, being familiar with both. F# really is faster and easier to work with. While yes, F# can't eliminate null references (even inside the language, you can force null) it is far less of an issue.
F# has some of its own libraries, and then also you'll find wrapper libraries to F#-ise other libs. The F# community seems very helpful and excellent. Even the F# team is far more engaged than C#'s ever was. I'm so impressed that once I emailed them with an issue, and Don Syme offered to get me a custom build to tide me over until my problem was officially fixed. This was well after F# has started gaining stream. They are very nice people, and amazingly competent.