Not at all. The class definition syntax is very terse and you can use the mutable keyword for imperative programming.
In fact, I think F# is a better imperative language than C#, if you choose to use it that way.
Yep this is my experience as well. isNull make it easy to pattern match on null, the only thing I really needed to have a terse way of dealing with outside word, either C# modules or IO that can have nulls. I was shocked how smooth everything is. I was productive maybe in 2 days without prior knowledge of the entire MS/.NET/C# world. The reason why I chose F# was because of the similarity to OCaml's syntax.
Can you back this up with some examples ? I feel it is exactly the opposite. For loops, mutable dictionary, in place updates to name a few imperative things you can do with easy in F#
But the .Net framework is mostly implemented C# / classes, so your F# code will always need to reference those objects from the stack which may be null etc. This is why I think MS is still building C# becuase a rewrite of .NET to pure f# is not worth it. My 2c.
The only cumbersome part is when you need to interop with C#. The .net event syntax is ridiculous for example.
The imperative features feel bolted on and underdeveloped. Just try to break out of a loop or do an early return in f#. The language really discourages the pure interface, impure implementation approach. I feel often compelled to use explicit tail recursion instead, which in turn feels like it's placed in a weird middle ground between a goto fest and structured programming.
If you allow early returns in a loop then loops are no longer expressions.
Why do you think it's intentional, and what could be done differently?