| - Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there. - Accessing the DB is easier in C# (just select a nice micro-ORM), type providers do not always cut it. - When using any kind of library that relies on anonymous types (e.g. Dapper for database access). - Tooling is still not complete, not being able to create directories in F# project (!) from IDE level (and even if you edit .fsproj, it can be a bit buggy) is really annoying in both web and desktop apps. - If you want to use some of object-oriented features e.g. co/contravariance in interfaces, protected access modifier. - (admittedly, that does not happen often) no unsafe context/keyword That being said, I agree that F# has a very sane set of defaults and I really like using F# for library work. |
The rest of the real arguments are essentially "library support". Which is a good argument, but not really about the language itself. There's no reason that WPF, DB access, etc. can't be just as fine in F#.
(C#'s limitations, like no tuples, led high-profile projects like ASP.NET MVC to do dumb hacks like "pass in an object and we'll assume each field is a parameter". If C# had been more capable in the first place, they wouldn't have resorted to such hacks.)