> How much work would it take in term of code rewriting?
There are definitely code changes required, but I think those are quite manageable as concepts mostly map 1:1 from OCaml to F#.
> can it compile to native code?
Yup, https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
> how good is the language support experience in vscode?
Pretty good, https://ionide.io
(but I personally prefer JetBrains Rider)
> any reason not to do it?
Compilation speed, some OCaml language features?
Also great to see a fellow HNer who uses the `service-name@personal-domain` email scheme, as per your profile!
It pains me to admit it because I really like F# but, with due respect to the developers, Ionide and its related projects are the most unstable toolchain I've ever used.
Spend half a day reloading the editor because the extension keeps hanging on non-trivial MSBuild only to discover that the formatter has truncated in half one of the files you worked on due to a soundness bug. (OCaml's editor support, in contrast, is quite stable.)
Rider is the best editing experience I've had with F#, by far.
I recommend Rider.
I was recently excited to try F# and prototype a web service within falco. Ionide worked until it didn’t in between switching from .net 6 to 7. Built fine but ide errors everywhere about missing modules
Probably a lot. Most of the operations on basic types like strings rely on C# methods rather than being implemented in the corresponding module like in OCaml (e.g. `String.split_on_char ' ' "a b c"` in OCaml vs `"a b c".Split(' ')` in F#). Type annotations on function parameters are required much more often because the compiler can't infer object types from a method call. Obviously you'll have very different libraries for doing the same things, and you'll be interacting with C# libraries a lot. Some language features like objects or binding operators exist in both languages but have very different syntax and differing semantics, and others like local opens and functors just don't exist in F#. F# also defaults to a "light" indentation-based syntax and I think the old OCaml-like syntax is either unsupported or hidden behind a compiler directive, and you'll probably want to rename identifiers from snake_case to camelCase.
> how good is the language support experience in vscode?
There's two competing LSP implementations for F#. Ionide works, but it's slow and it crashes and reports old errors for code you've just rewritten very often in my experience. fsharp-language-server seems to be a bit better in some aspects, but I haven't ever gotten it to work in VS Code.
It probably took longer than it had to: 30% of that time was devops, I wanted it to be bug-for-bug compatible so I spent a lot of time writing tests, and we were using some stuff which wasn't mature yet (new JSON serialization lib, compile to webassembly, binary serializers)
F#/.NET certainly has everything needed, and I find it a much simpler language than OCaml (eg no module games) - really it's what I hoped OCaml would be.
Also F# is .NET based, which has the clear benefit of adding a huge standard library, but at the same time the OOP-based design of .NET makes for uglier than necessary code in F#.