F# has many symbolic keywords that mean little or nothing for an average programmer. E.g. most people will have an idea what 'foo+bar' might mean, but very few people can predict the meaning of 'foo?:>bar', or intuitively tell the difference between '[<x>]' and '[|x|]', '<@x@>', '<@|x|@>', '<@@x@@>', and '<@@|x|@@>'. I guess, this is a flipside of shorter code. Anyhow, in my humble opinion '<@@|' takes it too far. The next station on that train is APL with expressions like (∼R∈R°.×R)/R←1↓ιR .

OCaml, the F# predecessor is not a pure functional language. It is a mix of functional and imperative/OO approach. Porting OCaml to .NET, whith its non-functional class library and object model reduced "functionness" and general language coherency even further. See "How much 'functional' is in F#?" for more details.

Most programmign languages that were commercially succesful in the last 40 or so years do not depend on the order of source files. Source files can be supplied to the compiler in any order, and the system magically figures it out. Not so in F#. It seems that F# completely lacks the concept of linker. If construct B uses construct A, the compiler must see the definition of A before the definition of B, or else you'll get "A is not defined" error. This means the developer must constantly keep in mind the right order of source files. It also has significant implications to the tools support quality, since modern tools like Visual Stuido are not designed for this kind of behavior.

In C# you can write const string fox = "The quick brown fox jumps over the lazy dog". In F# it is not currently possible. Microsoft F# team promised to fix this with [<Literal>] attribute in some future release, but currently it hurts badly, in particular in pattern matching. I ended up defining my literal in C# and referencing it from F#. Ugly-ugly-ugly.

Most compiler messages I received simply stated "syntax error". Paradoxically, as my F# skills improved and I started to make more "sofisticated" errors, compiler messages got better. Generally, "syntax error" is caused by the most trivial mistakes like forgotten equal sign or bracket. My hypothesis is that the F# compiler is tailored to the practical needs of the F# research team. Being quite advanced F# programmers, they don't make many stupid mistakes, and if they do, they can quickly figure out what's wrong. This is why simple mistakes yield "syntax error", while more sophisticated mistakes yield detailed diagnostics. Whatever the reason, current state of the compiler diagnostics is not acceptable for the general public. Beginner programmers will mostly make simple mistakes and will not know how to get out of it, and "syntax error" is not much of a help.

I already mentioned the source file order. Finding the right order is one problem. Maintaining that order is another. Every time you add a new file, it goes to the end. Every time you rename a file, it goes to the end. Current suggestion for changing the compilation order are outright ridiculous. They recommend to unload the project, change project file text by hand (!), and then reload the project. Another problem are assembly references. You cannot easily reference your F# projects from your C# projects and vice versa, even if they are in the same solution. You need to manually specify the references on the project settings level. All this may make maintaining large F# project a nightmare. And the prospects are not very bright here. I am afraid putting decent file order functionality into Visual Studio may be a challenge, since it is not designed for this kind of thing. From the other hand, some people are not as spoiled as I am. Someone commented on my blog that they "maintain F# code bases in excess of 250kLOC of code without a problem".