F# is not really for C# programmers, C# programmers just get by the F# features that keep being copied into C#.

F# is an ML that is kind of allowed to play on .NET because in a given moment management accepted to integrate it into Visual Studio, and keeps looking for the golden spot that it will take it beyond the VB/C# shadow, always a second thought when the .NET team designs new architecture features only taking VB and C# into consideration.

F# twittersphere is its own bubble, not always with nice opinions about Microsoft and the .NET platform it depends on.

I completely disagree that F# is for C# developers. For one, C# developers are usually fine sticking with C# and its massive ecosystem. F# and .NET more seamlessly run everywhere than Ocaml, which last time I tried is a lot of trouble on Windows. F# has had multicore support from the beginning and hasn’t needed a multi-year development process to get there.

I’d like to learn Ocaml (more than just the parts I’ve learned from F# and SML), but F# is by no means a simplistic language in terms of what you can accomplish. It’s easily one of the best designed and most pragmatic languages out there. From the syntax I have seen, F# is cleaner than Ocaml.

> F# is an ML dialect, like OCaml

That’s kind of splitting hairs. The object system is different for obvious reasons. F# clearly started as a port of a subset of Ocaml to .NET and was even valid Ocaml code for some time in the early days. That’s exactly a dialect.

Don Syme explains in history of F# that there were multiple efforts to port OCaml to .NET, (Nemerle comes to mind), but none of those felt natural to use.

For F#, they started with OCaml syntax and semantics; then modified it to make it a true .NET language. They added features that were not in OCaml like inheritance & interfaces. and removed features that were unnecessary in .NET like functors.

https://fsharp.org/history/hopl-final/hopl-fsharp.pdf Early F# compiler even had ml-compatibility mode which would make syntax closer to OCaml, it was probably used for bootstrapping.

Yes.

It was wrong of me to only mention the "limitations" (compared to OCaml) that "will drive you nuts", while saying nothing about extensions/advantages of F# - because, obviously, it does have some. This:

    printfn "%s" ((3.0 + 3.0).ToString())

may seem normal enough to onlookers, but being able to write it (more precisely, the mechanisms that make it possible) in F# can be seen as a definitive advantage over OCaml, where normal functions cannot be overloaded to work on multiple types. At least without explicitly handling it yourself, which can be a lot of work.

What I really wanted to say, but somehow failed, is that F# is not OCaml - it's a language in its own right, with both good and bad sides, which don't align with those of OCaml particularly well (and sometimes not at all). F# and OCaml share some semantic and syntactic features, but they are not "dialects" of each other (no matter which way you want to spin it), they have very different sets of trade-offs, and probably shouldn't be directly compared (even if such comparison was OK historically).

I think I failed to convey this properly because I was angry that "someone on the Internet!!!" mentioned F# in an OCaml thread "AGAIN!!!", even though it's definitely one of the biggest developments/successes on the OCaml side in recent memory. I mean, it's like you're having a party to celebrate your promotion, only to have that one person tell you all about how their cousin is better than you in every respect, and he didn't even need to work that hard for it, so you're just slow. It was strangely disconcerting, but I should have reacted less emotionally.

But basically no one uses the object part of OCaml

For various levels of no one.

GTK comes to mind