Some of the complaints in the article are certainly valid (why would there be early-return in the context of computation expressions, but not in ordinary functions?), but some I claim are actually features, and some are false.

* Linearly ordered files. Several times in F# I have tracked down an issue simply by bisecting the codebase, which is impossible in C# because there's no meaningful way to halve the code. I think I've only once ever had a problem with the linear ordering that wasn't solved simply by reordering some files.

* Explicit type conversions. I've only ever found this awkward when interfacing with C# code that is designed around C#'s extreme laxity. Explicit is better than implicit!

* "No struct tuples" is false - that's what the `struct` keyword is for. (It may have been true when the article was written.)

* Dot notation for indexing is now no longer necessary.

It's certainly true that OO idioms are often clunky and feel strangely like they were constructed by Frankenstein, but then I almost never find myself trying to use them anyway. You don't notice oddities in features which you never think of using! Similarly, the number of times I use `<-` is so low that I don't think of it as being incongruously odd - why shouldn't there be a baroque syntax to indicate the place in your code that's likely to have a 50% higher chance of bugs?