OCaml is cool, but have you tried F#?
Latest pivot is to try go heads up against Julia into Python's domain.
You already know which one data scientists will pick up.
I really don't like what has happened to C# is the past few years where features are just added blindly it seems. Current C# looks nothing like C# code from a few years ago and that's bad IMO.
On the horizon, discriminated unions are still being talked about, and more C++ performance like features.
Pattern Matching
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
Non destructive mutation
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
Null-coalescing assignment
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
I don't work in C#, but I must say, these seem like great features to me, and not too crufty/bloaty at all.
Scrolling through the other recent feature additions, they all look like things that would make a language feel smoother rather than more noisy. But again, IANAC#D.
I wrote C# daily before I switched to F# ~3 years ago and I sometimes struggle reading "modern" C# code. In C# you now often have multiple ways of doing the same thing.
But the community is interested in a lot of things, so F# doesn't have a real "singular" focus, like Go(backend systems/api's).
F#'s ties with Microsoft is a big productivity boon, but also seems to work against it sometimes...still the community really gets stuff done instead, because it's such a practical language!
Indeed, F# has the might of Microsoft behind it. Yet, to me, that carries some risk in itself. In the future, Microsoft might decide for some reason that F# is not aligned to its goals and say, it wants to invest in C# exclusively or decrease emphasis on F#. Then what happens?
OCaml is more resilient in a sense it is more "community" owned and run. Companies (contributing to OCaml) keep coming to (or leaving) OCaml. F# has all its eggs with Microsoft.
For us the tooling + library ecosystem are more important to get sh* done.
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#.
> 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.