Just Microsoft's rebrand and restricted version of OCaml. And, imho, it is much better to use original language (since it have much more features), especially with Core library.
While F# was definitely strongly influenced by OCaml, their features have diverged significantly. For example, F# has type providers, active patterns, and units of measure (though you're also right that OCaml has lots of features that F# doesn't, like first class modules).
Note also that this blog post is about accepting contributions to the Visual Studio IDE components for F#, not for the language itself (which has been open source for many years, and has already been accepting contributions from the community for a little while).
No, not at all. It is true that units are erased at runtime, but the compile time behavior is quite sophisticated, going well beyond anything that's possible in C# or OCaml. (Your link is quite interesting, but I think that using a custom build step is "cheating" to some degree in that you can add arbitrary features by adding language-external post build processing).
By being built into the language, units of measure in F# work naturally with type inference (and definitions can be measure-generic), so:
let weirdOperation (x:float<_>) (y:float<_>) = x * x + y * y * y
"I think that using a custom build step is "cheating" to some degree in that you can add arbitrary features by adding language-external post build processing"
I guess, but: source code is still standard C#, it gives you pre-runtime static verification. As far as I understand Roslyn will support this kind of extensibility in a straightforward way. It is still better than unit testing same stuff in my opinion (except for specifying units in comments).
"By being built into the language" - do you mean F# code that uses units of measure wouldn't compile to OCAML (I am talking about simple compilability rather than proper support)?
It's very nice to be able to check annotations in a build step. I'm just saying that adding language-external checks makes it fairly meaningless to say that "C#" supports it; would it be fair to say that C# supports all of Haskell's features if I require annotating C# constructs with Haskell code and then use a modified Haskell compiler in a post-build step to verify that the pieces are composed in a valid way? None of this is to say that the C# code you linked to is not useful - it's just not possible to use "vanilla" C# to achieve what "vanilla" F# can do.
To your later question, while F# and OCaml share a common core, there's lots of F# code that won't compile as OCaml and vice versa, and units of measure are one such example. The syntax for measure-annotated types is not valid OCaml syntax.
i just want to note that as far as i've seen, the ocaml community has little to no animosity towards f#. there are lots of ML dialects out there and the prevailing mood seems to be one of cooperation rather than competition - it's nice to see people explore the design space.
I mean, sure, you can use OCaml... unless you want/have to interop with .NET, then it doesn't matter how much you like OCaml, it's not going to solve your problem.
Please tell us how much time would it take you to build an OCAML app that would target: web, Android, iOS, Mac, Linux, Windows (desktop, store, phone), PS4 etc.?
