@mro Received mine! Thanks alot. It came as a surprise haha
There are alot of communalities. If you know one you know the other.
One small difference on syntax are:
-Ocaml uses keyword “in” and “;” operator , whereas F# uses indentation and spaces.
-F# uses <> around type types.
ocaml has a nice binding to the tk library to make a gui.
F# has not.
F# history is perfectly captured in The Early History of F# and how it relates to ML family of languages. There are missing / added language features on both sides, I missed the module system the most in F#.
On the practical side, I found developing F# to be quite foreign as a life long Unix person. The libraries from .NET really expect you to know C# and the build/package tooling had a distinct Windows feel to it. We used VS Code or Visual Studio for development, it worked ok, the .NET devs I worked with really liked it and the IDE experience. My preference is for Emacs as an editor, which I did manage to get working but it wasn’t that well integrated (it could have improved via lsp-mode in the last few years). The practicalities of using .NET libraries meant you had a library for almost anything, if you were ok wrapping it in F#, often the libraries had C# documentation and APIs, which felt very non-FP. Null pointers and mutablity from C# caused us problems at various times. F# is a decent choice if you already know and use Windows/.NET.
I might oversimplify but you convert a null-pointer to an option type and back ?
completely subjective and quite frankly useless opinion from my time playing with F#:
F# tooling has MS smell to it, OCaml tooling feels more UNIX-y. Also less ceremony and whatnot to produce e.g. an executable from a single file.
I like that OCaml is insensitive to indentation.
F# feels more pragmatic, but less satisfying. OCaml gives me more power while feeling leaner to work with
I envy some strides F# made, but I don’t like the idea of replicating them. I like that OCaml adds features in principled ways.
OCaml feels more coherent, things interact with each other more nicely.
F# has even worse value restriction rules than SML, let alone OCaml.
Nothing Ever Beats OCaml’s Compilation Speed™
It’s notable that OCaml has the benefits you list while being a bigger language (feature-wise).
yes you should do this especially when working with Option.ofObj or .ofNullable.
Very basically yes, it gets more complicated with larger structures that might contain nulls. Think of it as a validation boundary within the overall system, things from C# get checked and transformed to be safe for F# to use. I think of it similar to validating json data into domain types.
After spending some time with F# , i find the (F#/C#) libraries&API’s much better documented then the corresponding Ocaml libraries. Eg explicit examples are given.
I think I agree with most of this, but I kind of miss the need to manually arrange source files in compilation order just because it serves as documentation for newcomers starting to learn a codebase (with the first file not being dependent on any after it). Maybe there is something similar that can be automatically generated in OCaml and manual documentation is an option too.
Do you actually arrange source files? I never had to do that except in the project file itself.
The only arrangement is like this example. Some IDEs like Visual Studio and plugins like Ionide for VS Code give an easier way to arrange it than typing XML.
Others are welcome to answer too, but I’m especially interested in @dangdennis 's experience given the mention of IntelliJ/Rider
Question: Setting aside language differences of OCaml / F#, how does the IDE / tooling of OCaml (merlin + vscode + lsp) compare with F# (atleast IntelliJ support; also MS support?)
Personally, I’ve found IntelliJ/OCaml unseable, and neovim (via vscode backend) / OCaml to be useable bot unreliable (especially goto ref).
I’ve been working on marksman using Rider for a bit over a year now and the experience has been great.
- Find definition and references work reliably across modules,
- Refactors such as ‘rename’ work reliably across modules,
- Code completion and diagnostics are accurate and always up to date; I never needed to run a full build to get rid of stale diagnostics or discover new modules,
- Test runners are integrated.
- Debugger that works. It’s super easy to debug a test or attach a debugger to a running process. Now it’s not always 100% reliable. It can’t beat IntelliJ/Java debugging experience but it’s years ahead of what you can have in OCaml.
In my experience Rider for F# is better than Microsoft’s own Visual Studio. However, if you’re looking for something outside of big IDEs, you won’t find much:
- VSCode + Ionide LSP have been very unreliable to me.
- Emacs + FSAC LSP kind of works but no debugging, no test runners, very barebones.
In OCaml you can configure a pleasant working environment with dune + ocaml LSP + emacs/vim but there’s not much in terms of big IDE support. In F# it’s the reverse.
Why don’t you give it a try?
Rider is superb. F# is pretty nice too but I’m pretty sure I prefer OCaml. I feel it stays closer to FP fundamentals and I feel I can learn more with it.
For instance compare let operator syntax which is just a function definition away, to an F#’s computation expression, who’s implementation doesn’t look as elegant and simple to me.
I was going to create a thread to ask if it would be appropriate to use Ocaml.
I am working on a product that will use
- A web server
- An Android application
- An iOS application
But instead of using a language I am familiar with, like Python, Go or Java, I would like to develop it using a functional language.
In order of preference, the candidate languages are Ocaml, F#, LFE or Clojure (I don’t know any of them).
It seems to me that Ocaml is not “production ready” when we are talking about web frameworks, iOS and Android development.
I would really appreciate it if you could prove me wrong.
Thank you all.
Its hard to know what you need in these scenarios, but I wouldn’t hesitate to use OCaml for web development. Dream is designed such that I think it reasonable to build anything you might need that’s missing today.
Mobile development is way trickier, everything I’m aware of is still built on web tech. I know you can cross compile some business logic, but everything seems hard to trust in any future as both platforms continue to change. Depending on your needs, you can likely get something that’s workable across everything but it won’t be great anywhere without a lot of specialized effort.
All that say with the JS output options I don’t know of anything other than maybe dmDart that’s better unless you have dedicated codebases.
I realize this looks lazy on my part, but in my experience it generally takes a few months + 10k LOC to really figure out if the quirks in an Lang/IDE combo are (1) due to my own incompetence or (2) flaw in the Lang/IDE.