Looking at the new features, I get the distinct impression that the F# team has a clear vision of what work their language is suited for. It's meant to process data. These changes let more of your data pipeline happen within F#, extending up to, or even into, the data providers.
I really think F# benefits from being part of .NET instead of a stand-alone language. C# is probably better for designing a system, where you have a bunch of components swimming around talking to each other and maintaining state and dealing with the outside world and whatnot. F# is better for designing a process that takes input and produces output. That F# process can then be part of a C# system. That lets the F# team not have to worry so much about the system-y stuff, and design a tighter, more-focused language. (Ditto C#--from one point of view, .NET allows F# to be a DSL for C#).
I agree. F# and Scala are on the right track. Previous attempts to build total ecosystems around functional languages were too ambitious. In a mixed environment like this they can be allowed to shine doing the things they do best and programmers can ease their way into new paradigms with working code and familiar tools and libraries.
Unfortunately I think Scala is a little too indebted to Java/JVM and tries a little too hard to match the syntactic flexibility of Ruby. A Scala-- would be an easier sell, I think.
I read somewhere about using object-oriented languages for programming-in-the-large, and functional languages for programming-in-the-small. That is, using OO techniques for overall architecture and organization, and FP techniques to push data around. I should try to find a link...
I'd argue that F# is especially well-suited for a system with tons of components talking to each other. You have things like async workflows and message-passing built-in, along with the ability to do everything C# can do. I've been using F# to write such a system and I prefer it greatly to C#.
The only .NET thing I would recommend C# over F# for is UI.
I think it's because VS UI visual designer generates only C# code and doesn't work with other languages. Anyway you can build UI in C# and the rest in any .Net language you prefer.
I really think F# benefits from being part of .NET instead of a stand-alone language. C# is probably better for designing a system, where you have a bunch of components swimming around talking to each other and maintaining state and dealing with the outside world and whatnot. F# is better for designing a process that takes input and produces output. That F# process can then be part of a C# system. That lets the F# team not have to worry so much about the system-y stuff, and design a tighter, more-focused language. (Ditto C#--from one point of view, .NET allows F# to be a DSL for C#).