Yes, F# is a very nice language, however, it seems to me that I am making a somewhat forced comparison between OCaml and F# in the following section: https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f

OCaml does have an okay LSP implementation though, and it's getting better; certainly more stable than F#'s in my experience, since that comparison is coming up a lot in this comment section.

Correct. This is not the case when you talk about Java/Kotlin. Just ugliness and typical boilerplate heavy approach of JVM languages.

A case of a sum-type is an expression (of the variety so-called a type constructor), of course it has a type.

  datatype shape =
      Circle of real
    | Rectangle of real * real
    | Point

   Circle : real -> shape
   Rectangle : real * real -> shape
   Point : () -> shape

The moment you start ripping cases as distinct types out of the sum-type, you create the ability to side-step exhaustiveness and sum-types become useless in making invalid program states unrepresentable. They're also no longer sum-types. If you have a sum-type of nominally distinct types, the sum-type is contingent on the existence of those types. In a class hierarchy, this relationship is bizarrely reversed and there are knock-on effects to that.

> You declare the sum type once, and use it many times.

And you typically write many sum-types. They're disposable. And more to the point, you also have to read the code you write. The cost of verbosity here is underestimated.

> Slightly more verbose sum type declaration is worth it when it makes using the cases cleaner.

C#/Java don't actually have sum-types. It's an incompatible formalism with their type systems.

Anyways, let's look at these examples:

C#:

  public abstract record Shape;
  public sealed record Circle(double Radius) : Shape;
  public sealed record Rectangle(double Width, double Height) : Shape;
  public sealed record Point() : Shape;
  
  double Area(Shape shape) => shape switch
  {
      Circle c => Math.PI * c.Radius * c.Radius,
      Rectangle r => r.Width * r.Height,
      Point => 0.0,
      _ => throw new ArgumentException("Unknown shape", nameof(shape))
  };

  datatype shape =
      Circle of real
    | Rectangle of real * real
    | Point
  
  val result =
    case shape of
        Circle r => Math.pi * r * r
      | Rectangle (w, h) => w * h
      | Point => 0.0

Granted, this may just be an argument for being more comfortable reading/writing code in a particular style, but even without the advantages of LLMs adoption of functional paradigms and tools has been a struggle.

And then I didn't even make this "experiment" with Java or another managed, more imperative language which could have shed some weight due to not caring about manual memory management.

So not sure how much truth is in there - I think it differs based on the given program: some lend itself better for an imperative style, others prefer a more functional one.

Aside from the obvious problem that there's not enough FP in the training corpus, it seems like terser languages don't work all that well with LLMs.

My guess is that verbosity actually helps the generation self-correct... if it predicts some "bad" tokens it can pivot more easily and still produce working code.

Claude Code’s Haskell style is very verbose; if-then-elsey, lots of nested case-ofs, do-blocks at multiple levels of intension, very little naming things at top-level.

Given a sample of a simple API client, and a request to do the same but for another API, it did very well.

I concluded that I just have more opinions about Haskell than Java or Rust. If it doesn’t look nice, why even bother with Haskell.

I reckon that you could seed it with style examples that take up very little context space. Also, remind it to not enable language pragmas per file when they’re already in .cabal, and similar.

Use opam: https://opam.ocaml.org or https://opam.ocaml.org/doc/Install.html.

Additionally, see: https://ocaml.org/install#linux_mac_bsd and https://ocaml.org/docs/set-up-editor.

It is easy to set up with Emacs, for example. VSCodium has OCaml extension as well.

All you need for the OCaml compiler is opam, it handles all the packages and the compiler.

For your project, use dune: https://dune.readthedocs.io/en/stable/quick-start.html.

Do you have a ballpark value of how much faster Rust is? Also I wonder if OxCaml will be roughly as fast with less effort.

Modules are like structurally-typed records that can contain both abstract types and values/functions dependent on those types; every implementation file is itself a module. When passed to functors (module-level functions), they allow you to parameterize large pieces of code, depending on multiple types and functions, all at once quite cleanly. And simply including them or narrowing their signatures is how one exports library APIs.

(The closest equivalent I can imagine to module signatures is Scala traits with abstract type members, but structurally-typed and every package is an instance.)

However, they are a bit too verbose for finer-grained generics. For example, a map with string keys needs `module String_map = Map.Make(String)`. There is limited support for passing modules as first-class values with less ceremony, hopefully with more on the way.

Come on guys, this was old five years ago and its not organic, the strike force is quieter about brigading than it used to be, but you can still set your watch by it.

No way OCaml could have stolen the Rust's thunder: we have a number of very decent and performant GC-based languages, from Go to Haskell; we only had one bare-metal-worthy expressive language in 2010, C++, and it was pretty terrible (still is, but before C++11 and C++17 it was even more terrible).

But OCaml sadly can't replace F# for all my use cases. F# does get access to many performance-oriented features that the CLR supports and OCaml simply can't, such as value-types. Maybe OxCaml can fix that long term, but I'm currently missing a performant ML-like with a simple toolchain.