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.
Ocaml has been shipping with an actual fully functional reverse debugger for ages.
Is the issue mostly integration with the debugging ui of VS Code?
This has the benefit of giving you the ability to refer to a case as its own type.
> the expression of sums verbose and, in my view, harder to reason about.
You declare the sum type once, and use it many times. Slightly more verbose sum type declaration is worth it when it makes using the cases cleaner.
Correct. This is not the case when you talk about Java/Kotlin. Just ugliness and typical boilerplate heavy approach of JVM languages.
I have provided a case how using inheritance to express sum types can help in the use site. You attacked without substantiating your claim.
> This has the benefit of giving you the ability to refer to a case as its own type.
means.
I can tell.
Thankfully the OCaml textbook has this explicitly called out.
https://dev.realworldocaml.org/variants.html#combining-records-and-variants
> The main downside is the obvious one, which is that an inline record can’t be treated as its own free-standing object. And, as you can see below, OCaml will reject code that tries to do so.
- create a separate record type, which is no less verbose than Java's approach
- use positional destructuring, which is bug prone for business logic.
Also it's funny that you think OCaml records are "with better syntax". It's a weak part of the language creating ambiguity. People work around this qurik by wrapping every record type in its own module.
https://dev.realworldocaml.org/records.html#reusing-field-names
```ocaml
type _ treated_as =
| Int : int -> int treated_as
| Float : float -> float treated_as
let f (Int x) = x + 1 (* val f : int treated_as -> int *)
```
```ocaml
let f = function
| `Foo x -> string_of_int (x + 1)
| `Bar x -> x ^ "Hello"
(* val f : [< `Foo of int | `Bar of string] -> string` *)
let g = function
| `Foo _ -> ()
| _ -> ()
(* val g : [> `Foo of 'a ] -> unit *)
```And since OCaml has also an object model, you can also encoding sum and sealing using modules (and private type abreviation).
A meta point: it seems to me that a lot of commenters in my thread don't know that vanilla HM cannot express subtypes. This allows the type system to "run backwards" and you have full type inference without any type annotations. One can call it a good tradeoff but it IS a tradeoff.
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
Quite the opposite, that gives me the ability to explicitly express what kinds of values I might return. With your shape example, you cannot express in the type system "this function won't return a point". But with sum type as sealed inheritance hierarchy I can.
> C#/Java don't actually have sum-types.
> They're pretty much the same
Not sure about C#, but in Java if you write `sealed` correctly you won't need the catch-all throw.
If they're not actual sum types but are pretty much the same, what good does the "actually" do?
Will the compiler check that you have handled all the cases still? (Genuinely unsure — not a Java programmer)
https://openjdk.org/jeps/409#Sealed-classes-and-pattern-matching
> with pattern matching for switch (JEP 406)the compiler can confirm that every permitted subclass of Shape is covered, so no default clause or other total pattern is needed. The compiler will, moreover, issue an error message if any of the three cases is missing
Sure you can, that's just subtyping. If it returns a value that's not a point, the domain has changed from the shape type and you should probably indicate that.
structure Shape = struct
datatype shape =
Circle of real
| Rectangle of real * real
| Point
end
structure Bound = struct
datatype shape =
Circle of real
| Rectangle of real * real
end
That's not to say it's the only way to solve this problem, though. And for heavy-duty problems, you typically write something like this using higher-kinded polymorphism:
signature SHAPE_TYPE = sig
datatype shape =
Circle of real
| Rectangle of real * real
| Point
val Circle : real -> shape
val Rectangle : real * real -> shape
val Point : shape
end
functor FullShape () : SHAPE_TYPE = struct
datatype shape =
Circle of real
| Rectangle of real * real
| Point
val Circle = Circle
val Rectangle = Rectangle
val Point = Point
end
functor RemovePoint (S : SHAPE_TYPE) :> sig
type shape
val Circle : real -> shape
val Rectangle : real * real -> shape
end = struct
type shape = S.shape
val Circle = S.Circle
val Rectangle = S.Rectangle
end
structure Shape = FullShape()
structure Bound = RemovePoint(Shape)
Anyways, in both cases, this is now just:
DoesNotReturnPoint : Shape.shape -> Bound.shape
> If they're not actual sum types but are pretty much the same, what good does the "actually" do?
Conflation of two different things here. The examples given are syntactically similar, and they're both treating the constituent part of the grammar as a tagged union. The case isn't any cleaner was the point.
However in the broader comparison between class hierarchies and sum-types? They're not similar at all. Classes can do some of the things that sum-types can do, but they're fundamentally different and encourage a completely different approach to problem-solving, conceptualization and project structure... in all but the most rudimentary examples. As I said, my 2nd example here is far closer to a class-hierarchy system than sum-types, though it's still very different. And again, underlining that because of the properties of sum-types, thanks to their specific formalization, they're capable of things class hierarchies aren't. Namely, enforcing valid program-states at a type-level. Somebody more familiar with object-oriented formalizations may be a better person to ask than me on why that is the case.
It's a pretty complicated space to talk about, because these type systems deviate on a very basic and fundamental level. Shit just doesn't translate well, and it's easy to find false friends. Like how the Japanese word for "name" sounds like the English word, despite not being a loan word.
Anyway, to translate your example:
sealed interface Shape permits Point, Bound {}
final class Point implements Shape {}
sealed interface Bound extends Shape permits Circle, Rectangle {}
record Circle(double radius) implements Bound {}
record Rectangle(double width, double height) implements Bound {}
> the Japanese word for "name" sounds like the English word, despite not being a loan word.
Great analogy, except for the fact that someone from the Java team explicitly said they're drawing inspirations from ML.
Substantiate this.
> weird name choice but whatever
I don't think this kind of snarky potshot is in line with the commentary guidelines. Perhaps you could benefit from a refresher?
https://news.ycombinator.com/newsguidelines.html#comments
> Thanks to subtyping, no contortion needed
I see the same degree of contortion, actually. Far more noisy, at that.
> No need to use 7 more lines to create a separate, unrelated type.
You're still creating a type, because you understand that a sum-type with a different set of cases is fundamentally a different type. Just like a class with a different set of inheritance is a different type. And while it's very cute to compress it all into a single line, it's really not compelling in the context of readability and "write once, use many". Which is the point you were making, although it was on an entirely different part of the grammar.
> Great analogy, except for the fact that someone from the Java team explicitly said they're drawing inspirations from ML.
ML didn't invent ADTs, and I think you know it's more than disingenuous to imply the quotation means that the type-system in Java which hasn't undergone any fundamental changes in the history of the language (nor could it without drastically changing the grammar of the language and breaking the close relationship to the JVM) was lifted from ML.
You never gave an example how sum types in Java/Kotlin cannot do what "real" sum types can.
>> weird name choice but whatever
> snarky potshot
Sorry that you read snark. What I meant was "I find naming this 'Bound' weird. But since I am translating your example, I'll reuse it".
> You're still creating an unrelated type
How can a type participating in the inheritance hierarchy be "unrelated"?
> I see the same degree of contortion, actually. Far more noisy, at that.
At this point I can only hope you're a Haskeller and do not represent an average OCaml programmer.
Operationally these systems and philosophies are quite different, but mathematically we are all working in more work less an equivalent category and all the type system shenanigans you have in FP are possible in OOP modulo explicit limits placed on the language and vice versa.
Me neither.
> you are entirely correct that sealed types can fully model sum types
I want to be wrong, in that case I learn something new.
One thing I am wondering about in the age of LLMs is if we should all take a harder look at functional languages again. My thought is that if FP languages like OCaml / Haskell / etc. let us compress a lot of information into a small amount of text, then that's better for the context window.
Possibly we might be able to put much denser programs into the model and one-shot larger changes than is achievable in languages like Java / C# / Ruby / etc?
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.
I’d believe that, but I haven’t tried enough yet. It seems to be doing quite well with jq. I wonder how its APL fares.
When Claude generates Haskell code, I constantly want to reduce it. Doing that is a very mechanical process; I wonder if giving an agent a linter would give better results than overloading it all to the LLM.
The power of Haskell in this case is the fearless refactoring the strong type system enables. So even if the code generated is not beautiful, it can sit there and do a job until the surrounding parts have taken shape, and then be refactored into something nice when I have a moment to spare.
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.
My experience in the past with something like cats-effect has been that there are straightforward things that aren't obvious, and if you haven't been using it recently, and maybe even if you've been using it but haven't solved a similar problem recently, you can get stuck trawling through the docs squinting at type signatures looking for what turns out to be, in hindsight, an elegant and simple solution. LLMs have vastly reduced this kind of friction. I just ask, "In cats-effect, how do I...?" and 80% of the time the answer gets me immediately unstuck. The other 20% of the time I provide clarifying context or ask a different LLM.
I haven't done enough maintenance coding yet to know if this will radically shift my view of the cost/benefit of functional programming with effects, but I'm very excited. Writing cats-effect code has always been satisfying and frustrating in equal measure, and so far, I'm getting the confidence and correctness with a fraction of the frustration.
I haven't unleashed Claude Code on any cats-effect code yet. I'm curious to see how well it will do.
For instance, dependent types allow us to say something like "this function will return a sorted list", or even "this function will return a valid Sudoku solution", and these things will be checked at compile time--again, at compile time.
Combine this with an effect system and we can suddenly say things like "this function will return a valid Sudoku solution, and it will not access the network or filesystem", and then you let the LLM run wild. You don't even have to review the LLM output, if it produces code that compiles, you know it works, and you know it doesn't access the network or filesystem.
Of course, if LLMs get a lot better, they can probably just do all this in Python just as well, but if they only get a little better, then we might want to build better deterministic systems around the unreliable LLMs to make them reliable.
Rather, immutability/purity is a huge advantage because it plays better with the small context window of LLM's. An LLM then doesn't have to worry about side effects or mutable references to data outside the scope currently being considered.
The expressive type system catches a lot of mistakes, and the fact that they are compile errors which can be fed right into the LLM again means that incorrect code is caught early.
The second is property based testing. With it I have had the LLM generate amazingly efficient, correct code, by iteratively making it more and more efficient – running quickcheck on each pass. The LLM is not super good at writing the tests, but if you add some yourself, you quickly root out any mistakes in the generated code.
This might not be impossible to achieve in other languages, but I haven’t seen it used as prevailently in other languages.
Wanting to use a functional language I pivoted to fsharp, which was not the expected choice for me as I use Linux exclusively. I have been happy with this choice, it has even become my preferred language. The biggest problem for me was the management of the fsharp community, the second class citizen position of fsharp in the DotNet ecosystem, and Microsoft's action screwing the goodwill of the dev community (eg hot reload episode). I feel this hampered the growth of the fsharp community.
I'm now starting to use rust, and the contrast on these points couldn't be bigger.
Edit: downvoters, caring to share why? I thought sharing my experience would have been appreciated. Would like to know why I was wrong.
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.
Can you be more specific?
(Why the down-vote? He does need to be specific, right? Additionally, my experiences are somehow invalid?)
RUN eval $(opam env) && opam install --yes dune=3.7.0
RUN eval $(opam env) && opam install --yes dune=3.19.1
Additionally, see: https://dune.readthedocs.io/en/stable/tutorials/dune-package-management/setup.html.
Anyways, what you could do is:
opam pin add dune 3.7.0
opam install dune
opam pin add dune https://github.com/ocaml/dune/releases/download/3.7.0/dune-3.7.0.tbzNevertheless, I have fond memories of OCaml and a great amount of respect for the language design. Haven't checked on it since, probably should. I hope part of the problems have been solved.
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.
The Dune build system does default to ocamlopt nowadays, although maybe not back around 2020.
Strong stance on Modules. My ignorance, what do they do that provides that much benefit. ??
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.
[1]: Practically speaking, the 31-bit Ints are annoying if you're trying to do any bit bashing, but aesthetically the double semicolons are an abomination and irk me far more.
When I see Rust topping the "most loved language" on Stack Overflow etc. what I think is really happening is that people are using a "modern" language for the first time. I consistently see people gushing about, e.g., pattern matching in Rust. I agree pattern matching is awesome, but it is also not at all novel if you are a PL nerd. It's just that most commercial languages are crap from a PL nerd point of view.
So I think "no gc but memory safe" is what got people to look at Rust, but it's 1990s ML (ADTs, pattern matching, etc.) that keeps them there.
[1]: https://github.com/oxcaml/oxcaml
[2]: https://docs.scala-lang.org/scala3/reference/experimental/cc.html
I think it was more about "the performance of C, but with memory safety and data race safety".
Yeah; this is my experience. I've been working in C professionally lately after writing rust fulltime for a few years. I don't really miss the borrow checker. But I really miss ADTs (eg Result<>, Option, etc), generic containers (Vec<T>), tuples, match expressions and the tooling (Cargo).
You can work around a lot of these problems in C with grit and frustration, but rust just gives you good answers out of the box.
A lot of effort went into making it efficient thanks to the web, while python sorta has its hands tied back due to exposing internals that can be readily used from C.
OCaml's GC design is a pretty simple one: two heaps, one for short-lived objects and another one for the long-lived objects, and it is a generational and mostly non-moving design. Another thing that helps tremendously is the fact that OCaml is a functional programming language[1], which means that, since values are never mutated, most GC objects are short or very short-lived and never hit the other heap reserved for the long-lived objects, and the short-lived objects perish often and do so quickly.
So, to recap, OCaml’s GC is tuned for simplicity, predictable short pauses, and easy interoperability, whereas Java’s GC is tuned for maximum throughput and large-scale heap management with sophisticated concurrency and compaction.
[0] Maybe it still is – I am not sure.
[1] It is actually a multiparadigm design, although most code written in OCaml is functional in its style.
That surely has a performance cost.
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).
In many use cases even if the performance is within the project delivery deadlines there will worthless discussions about performance benchmarks completly irrelevant to the task at hand.
And ironically many of the same folks are using Electron based apps for their workflows.
Kotlin is definitely available at Google, but when talking about sym types et al it's not nearly as nice to use as Rust / OCaml.
I definitely find it (and jetpack compose) make developing android apps a much better experience than it used to be.
What I like a lot about Kotlin are its well written documentation and the trailing lambdas feature. That is definitely directly OCaml inspired (though I also recently saw it in a newer language, the "use" feature in Gleam). But in Kotlin it looks nicer imo. Allows declarative code to look pretty much like json which makes it more beginner friendly than the use syntax.
But Kotlin doesn't really significantly stand out among Java, C#, Swift, Go, etc. And so it is kind of doomed to be a somewhat domain specific language imo.
If that wasn't the case, Google would support Java latest with all features, alongside Kotlin, and let the best win.
See how much market update Kotlin has outside Android, when it isn't being pushed and needs to compete against Java vLatest on equal terms.
Android is Google's J++, which Sun sued and won.
Kotlin is Google's C#.
Plus everyone keeps forgetting Kotlin is a JVM based language, Android Studio and Gradle are implemented in JVM languages, JVM are implemented in a mix of C, C++ and Java (zero Kotlin), Android still uses Java, only that Google only takes out of OpenJDK what they feel like, and currentl that is Java 17 LTS, most of the work on OpenJDK was done by Oracle employees.
I think it will be very hard for us to find anything in common to agree on then.
Anyway, it’s pretty clear Google is pushing Kotlin because they don’t want to have anything to do with Oracle which has not been cleared by the verdict of their last trial. The situation has nothing to do with anything technical.
Blaming them for pushing Kotlin when the alternative you offer is them using a language they have already been sued for their use of seems extremely misguided to me.
I call them dishonest by comparing outdated Java 7 subset with Kotlin, when back in 2017 the latest version was Java 9, and in 2025 it is Java 24, and yet the documentation keeps using Java 8 for most examples on Java versus Kotlin.
How come Google doesn't want to have anything with Oracle, when it is impossible to build an Android distribution without a JVM, again people like yourself keep forgeting OpenJDK is mostly a product from Oracle employees (about 80%) with remaing efforts distributed across Red-Hat(IBM), IBM, Azul, Microsoft and JetBrains (I wonder what those do on Android), Kotlin doesn't build for Android without a JVM implementation, Gradle requires a JVM implementation, Android Studio requires a JVM implementation, Maven Central has JVM libraries,....
If Google doesn't want anything to do with Oracle why aren't they using Dart, created by themselves, instead of a language that is fully dependent on Oracle's kigdom for its own very existence?
Kotlin has a very similar syntax to Groovy, which already had that feature (it looks identical in Groovy and Kotlin)... and I believe Groovy itself took that from Ruby, I believe (Groovy tried to add most convenient features from Python and Ruby). Perhaps that is what came from OCaml?? No idea, but I'd say the chance Kotlin copied Groovy is much higher as JB was using Java and Groovy before Kotlin existed.
People agree to go to great lengths to use a tool that has some kind of superpower, despite syntactic weirdness or tooling deficiencies. People study and use LISP descendants like Clojure, APL descendants like K, "academic" languages like Haskell and OCaml, they write hobby projects in niche languages like Nim or Odin, they even use even C++ templates.
Why is Ada so under-represented? It must have a very mature ecosystem. I suspect that it's just closed-source mostly, and the parties involved don't see much value in opening up. If so, Ada is never going to make it big, and will slowly retreat under the pressure of better-known open alternatives, even in entrenched areas like aerospace.
https://www.ghs.com/products/ada_optimizing_compilers.html
https://www.ptc.com/en/products/developer-tools/apexada
https://www.ddci.com/products_score/
http://www.irvine.com/tech.html
http://www.ocsystems.com/w/index.php/OCS:PowerAda
http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm
Ada was too hardware demanding for the kind of computers people could afford at home, we could already do our Ada-like programming with Modula-2 and Object Pascal dialect hence how Ada lost home computing, and FreePascal/Delphi would be much more used today, had it not been for Borland getting too gready.
On big iron systems, espcially among UNIX vendors they always wanted extra bucks for Ada.
When Sun started the trend of UNIX vendors to charge for the developer tools as an additional SKU, Ada wasn't part of the package, rather an additional license on top, so when you already pay for C and C++ compilers, why would someone pay a few thousand (select currency) more if not required to do so, only because of feeling good writing safer software, back in the days no one cared about development cost of fixing security bugs.
(They are the same language)
Reason at least was an active collaboration between several projects in the OCaml space with some feedback into OCaml proper (even though there was a lot of initial resistance IIRC).
Whereas the Go and Rust communities, for example, were just fine with having corporate sponsorship driving things.
They really don't, less than 5% of opam packages depend on Base and that's their bottom controversial dependency I'd say. Barely anyone's complaining about their work on the OCaml platform or less opinionated libraries. I admit the feeling that they do lingers, but having used OCaml in anger for a few years I think it's a non-issue.
What they do seem to control is the learning pipeline, as a newcomer you find yourself somewhat funneled to Base, Core, etc. I tried them for a while, but eventually understood I don't really need them.
But going way back while yeah the team at Google controlled the direction, there were some pretty significant contributions from outside to channels, garbage collection, and goroutines and scheduling..
Arguably, that could have been Scala and for a while it seemed like it would be Scala but then it kind of just... didn't.
I suspect some of that was that the programming style of some high profile Scala packages really alienated people by pushing the type system and operator overloading much farther than necessary.
It tries to be a better Java and a better OCaml at the same time. This split personality led to Scala’s many dialects, which made it notorious for being difficult to read and reason about, particularly as a mainstream language contender.
Above all, Scala is considered a functional language with imperative OOP qualities. And it more or less fits that description. But like it or not primarily functional languages don’t have a strong reputation for building large maintainable enterprise software.
That’s the quiet part no one says out loud.
It’s like how in academic circles Lisp is considered the most pure and most powerful of programming languages, which may be true. At the same time most real-world decision makers see it as unsuitable as a mainstream language. If it were otherwise, we’d have seen a Lisp contend with imperative langs such as Java, C#, TypeScript, etc.
I’ve always attributed this disconnect to the fact that people naturally model the world around them as objects with state — people don’t think functionally.
I think they have been optional for like 20 years, except in the top-level interactive environment to force execution.
That being said, I still don't get why people are so much upset with the syntax. You'll integrate it after a week writing OCaml code.
And I think a big part of the reason that Elixir has done so well (Elixir pretty much starting out as Erlang-but-with-Ruby-syntax)
The great thing is we have choice. We have a huge number of ways to express ideas and ... do them!
I might draw a parallel with the number of spoken languages extent in the UK (only ~65M people). You are probably familiar with English. There are rather a lot more languages here. Irish, Scottish, Welsh - these are the thriving Brythonic languages (and they probably have some sub-types). Cornish formally died out in the sixties (the last two sisters that spoke it natively, passed away) but it has been revived by some locals and given that living people who could communicate with relos with first hand experience, I think we can count that a language that is largely saved. Cumbric ... counting still used by shepherds - something like: yan, tan, tithera toe.
I am looking at OCAML because I'm the next generation to worry about genealogy in my family and my uncle has picked Geneweb to store the data, taking over from TMG - a Windows app. His database contains roughly 140,000 individuals. Geneweb is programmed in OCAML.
If you think that programming languages are complicated ... have a go at genealogy. You will soon discover something called GEDCOM and then you will weep!
Choice is good of course so do keep up the good work.
That's about the time-frame where I got into OCaml so I followed this up close.
The biggest hindrance in my opinion is/was boxed types.
Too much overhead for low level stuff, although there was a guy from oxbridge doing GL stuff with it.
No, that wouldn't have made the difference. No-one didn't pick up OCaml because it didn't have multicore or they were annoyed by the semicolons.
People don't switch languages because the new language is "old language but better". They switch languages because a) new language does some unique thing that the old language didn't do, even if the unique thing is useless and irrelevant, b) new language has a bigger number than old language on benchmarks, even if the benchmark is irrelevant to your use case, or c) new language claims to have great interop with old language, even if this is a lie.
There is no way OCaml could have succeeded in the pop culture that is programming language popularity. Yes, all of the actual reasons to use Rust apply just as much to OCaml and if our industry operated on technical merit we would have migrated to OCaml decades ago. But it doesn't so we didn't.
People wouldn't care much for Rust at all if it didn't offer two things that are an absolute killer feature (that OCaml does not have):
* no GC, while being memory safe.
* high performance on par with C while offering no-cost high level conveniences.
There's no other language to this day that offers anything like that. Rust really is unique in this area, as far as I know.
The fact that it also has a very good package manager and was initially backed by a big, trusted company, Mozzila, while OCaml comes from a Research Lab, also makes this particular race a no-brainer unless you're into Functional Programming (which has never been very popular, no matter the language).
Haskell of course has some of this, but immutability means that Haskell doesn't have to have answers for lots of things. And you want pattern matching as your basic building block, but at the end of the day most of your code won't have pattern matching and will instead rely on higher level patterns (that can build off of ADTs providing some degree of certainty on totality etc)
Many academically-trained developers never got exposed to FP in school, and to this day you can still hear, albeit in much lesser numbers thanks to the popularity of Elixir/Clojure/etc., the meme of FP being "hard" perpetuated.
---
1: I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory when all you want is a for loop and a mutable data-structure.
2: I played with OCaml 10+ years ago, and couldn't make head or tails of it. I tried again recently, and it just felt familiar and quite obvious.
> I'm certain the meme was mostly born out of unfamiliarity
> I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory
Maybe I got lucky being in one of the most relevant universities in Portugal, however I can tell that others in the country strive for similar quality for their graduates, even almost 40 years later.
I am no strage to ML type systems, my first one was Caml Light, OCaml was still known as Objective Caml, and Mirada was still something being discussed on programming language lectures on my university.
From what I see, I also kind of find the same, too many people rush out for Rust thinking that ML type systems is something new introduced by Rust, without having the background where all comes from.
I don't think it was on-device code, as they talked about porting Python projects. But you can watch the talk to see if I'm misremembering.
Just Arc, clone and panic your way to success! :)
* OPAM is quite buggy and extremely confusing.
* Windows support is very bad. If you ever tried to use Perl on Windows back in the day... it's worse than that.
* Documentation is terse to the point of uselessness.
* The syntax style is quite hard to mentally parse and also not very recoverable. If you miss some word or character the error can be "the second half of the file has a syntax error". Not very fun. Rust's more traditional syntax is much easier to deal with.
Rust basically has none of those issues. Really the only advantage I can see with OCaml today is compile time, which is important, but it's definitely not important enough to make me want to use OCaml.
The only contact with OCaml I had was that I wrote a bug report to a university professor because I wanted his tool to process one of my files, but the file was larger than OCaml's int type could handle. That itself wasn't the problem - he wrote it wasn't straight forward to fix it. (This is a bug of the type "couldn't have happened in Common LISP". But I guess even in C one could replace int by FILE_SIYE_TYPE and #define it as unsigned size_t, for instance).
OCaml had its act together. It was significantly nicer than Python when I used it professionally in 2010. Just look at what JaneStreet achieved with it.
The main impediment to OCaml was always that it was not American nor mainly developed from the US.
People like to believe there is some technical merit to language popularity but the reality it’s all fashion based. Rust is popular because they did a ton of outreach. They used to pay someone full time to mostly toot their horn.
ReasonML has custom operators that allows for manipulating monads somewhat sanely (>>= operators and whatnot). rescript (reasonml’s “fork”) did not last time I checked. But it does have an async/await syntax which helps a lot with async code. reasonml did not last time I checked, so you had to use raw promises.
I believe Melange (which the article briefly talks about) supports let bindings with the reason syntax.
And this kinda changes everything if you React. Because you can now have sane JSX with let bindings. Which you could not until melange. Indeed, you can PPX your way out of it in ocaml syntax, but I’m not sure the syntax highlight works well in code editors. It did not on mine anyway last time I checked.
So for frontend coding, Melange’s reason ml is great as you have both, and let bindings can approximate quite well async syntax on top of writing readable monadic code.
For backend code, as a pythonista, I hate curlies. and I do like parenthesis-less function calls and definitions a lot. But I still have a lot of trouble, as a beginner ocamler, with non-variable function argument as I need to do “weird” parenthesis stuff.
Hope this “helps”!
I’ve always been curious about OCaml, especially since some people call it “Go with types” and I’m not a fan of writing Rust. But I’m still not sold on OCaml as a whole, its evangelists just don’t win me over the way the Erlang, Ruby, Rust, or Zig folks do. I just cant see the vision
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.
And the best way I can describe why is that my code generally ends up with a few heavy functions that do too much; I can fix it once I notice it, but that's the direction my code tends to go in.
In my OCaml code, I would look for the big function and... just not find it. No single workhorse that does a lot - for some reason it was just easier for me to write good code.
Now I do Rust for side projects because I like the type system - but I would prefer OCaml.
I keep meaning to checkout F# though for all of these reasons.
Real life sample:
let print_expr exp =
(* Local function definitions *)
let open_paren prec op_prec =
if prec > op_prec then print_string "(" in
let close_paren prec op_prec =
if prec > op_prec then print_string ")" in
let rec print prec exp = (* prec is the current precedence *)
match exp with
Const c -> print_float c
| Var v -> print_string v
| Sum(f, g) ->
open_paren prec 0;
print 0 f; print_string " + "; print 0 g;
close_paren prec 0
| Diff(f, g) ->
open_paren prec 0;
print 0 f; print_string " - "; print 1 g;
close_paren prec 0
| Prod(f, g) ->
open_paren prec 2;
print 2 f; print_string " * "; print 2 g;
close_paren prec 2
| Quot(f, g) ->
open_paren prec 2;
print 2 f; print_string " / "; print 3 g;
close_paren prec 2
in print 0 exp;;
let print_expr exp =
Also, you need to end the declaration with `in`?
Then, semicolons...
open_paren prec 0;
print 0 f; print_string " + "; print 0 g;
print 0 exp;;
I actually really like the syntax of OCaml, its very easy to write and when you're used to it, easy to read (easier than reasonml IMO).
Double semicolons are afaik only used in the repl.
The syntax is `let <constantname> <parameters> = <value> in <expression>;;` where `expression` can also have `let` bindings.
So you can have
let one = 1 in
let two = 2 in
let three = one + two in
print_endline (string_of_int three);; let x = v in expr
In essence, an OCaml program is a giant recursive expression, because `expr` can have its own set of let definitions.
In the REPL, this is where the double semicolons come in, as a sort of hint to continue processing after the expression.
YMMV but let expressions are one of the nice things about OCaml - the syntax is very clean in a way other languages aren't. Yes, the OCaml syntax has some warts, but let bindings aren't one of them.
It's also quite elegant if you consider how multi-argument let can be decomposed into repeated function application, and how that naturally leads to features like currying.
> Also, you need to end the declaration with `in`?
Not if it's a top level declaration.
It might make more sense if you think of the `in` as a scope operator, eg `let x = v in expr` makes `x` available in `expr`.
> Then, semicolons...
Single semicolons are syntactic sugar for unit return values. Eg,
print_string "abc";
let () = print_string "abc" inA sum type has as many possible values as the sum of its cases. E.g. `A of bool | B of bool` has 2+2=4 values. Similarly for product types and exponential types. E.g. the type bool -> bool has 2^2=4 values (id, not, const true, const false) if you don't think about side effects.
Not the best example since 2*2=4 also.
How about this bit of Haskell:
f :: Bool -> Maybe Bool
f False = Nothing
f False = Just True
f False = Just False
f True = Nothing
f True = Just True
f True = Just False
EDIT: Nevermind, I counted wrong. Here are the 9:
f x = case x of
True -> Nothing
False -> Nothing
f x = case x of
True -> Nothing
False -> Just False
f x = case x of
True -> Nothing
False -> Just True
f x = case x of
True -> Just False
False -> Nothing
f x = case x of
True -> Just False
False -> Just False
f x = case x of
True -> Just False
False -> Just True
f x = case x of
True -> Just True
False -> Nothing
f x = case x of
True -> Just True
False -> Just False
f x = case x of
True -> Just True
False -> Just TrueEDIT: now you see why I used the smallest type possible to make my point. Exponentials get big FAST (duh).
f1 False = Nothing, f1 True = Nothing
f2 False = Nothing, f2 True = Just True
...
This gives the correct 3^2 = 9 functions.
Here is my uneducated guess:
In math, after sum and product, comes exponent :)
So they may have used that third term in an analogous manner in the example.
The type A → (B → C) is isomorphic to (A × B) → C (via currying). This is analogous to the rule (cᵇ)ᵃ = cᵇ˙ᵃ.
The type (A + B) → C is isomorphic to (A → C) × (B → C) (a function with a case expression can be replaced with a pair of functions). This is analogous to the rule cᵃ⁺ᵇ = cᵃ·cᵇ.
There are ppx things that can automatically derive "to string" functions, but it's a bit of effort to set up, it's not as nice to use as what's available in Rust, and it can't handle things like Set and Map types without extra work, e.g. [1] (from 2021 so situation may have changed).
Compare to golang, where you can just use "%v" and related format strings to print nearly anything with zero effort.
[1] https://discuss.ocaml.org/t/ppx-deriving-implementation-for-pretty-printing-sets-maps/9004
Python does it best from what I've seen so far, with its __repr__ method.
I saw this in the OP:
>For example, creating a binding with the Tk library
and had also been thinking about this separately a few days ago, hence the question.
- No HKTs "in your sense" but: ```ocaml module type S = sig type 'a t end `` `type 'a t` is an Higher Kinded type (but in the module Level). - No typeclasses, yes, for the moment but the first step of https://arxiv.org/pdf/1512.01895 is under review: https://github.com/ocaml/ocaml/pull/13275 - no call-site expansion ? https://ocaml.org/manual/5.0/attributes.html look at the attribute `inline`.
The type system usually means that I might take longer to get my code to compile, but that I won’t spend much (if any) time debugging it once I’m done.
I’m in the middle of pulling together bits of a third party library and refactoring them over several days work, and I’m pretty confident that most of the issues I’ll face when done will be relatively obvious runtime ones.
Even the object system which most OCaml developers avoid, is actually very useful for some specific modelling scenarios (usually hierarchies in GUIs or IaC) that comes with similar type system guarantees and minimal type annotations.
The most involved project I did with it was a CRUD app for organising Writer's Festivals.
The app was 100% OCaml (ReasonML so I could get JSX) + Dream + HTMX + DataTables. I used modules to get reusable front end templates. I loved being able to make a change to one of my data models and have the compiler tell me almost instantly where the change broke the front end. The main value of the app was getting data out of excel into a structured database, but I was also able to provide templated and branded itineraries in .odt format, create in memory zipped downloads so that I didn't need to touch the server disk. I was really impressed by how much I could achieve with the ecosystem.
But having to write all my database queries in strings and then marshal the data through types was tiring (and effectively not compile time type checked) and I had to roll my own auth. I often felt like I was having to work on things that were not core to the product I was trying to build.
I've spent a few years bouncing around different languages and I think my take away is that there is no perfect language. They all suck in their own special way.
Now I'm building an app just for me and I'm using Rails. Pretty much everything I've wanted to reach for has a good default answer. I really feel like I'm focused on what is relevant to the product I'm building and I'm thinking about things unrelated to language like design layout and actually shipping the thing.
Also, I had no idea that the module system had its own type system, that’s wild.
> The idea that the example program could use pattern matching to bind to either test values or production ones is interesting, but I can’t conceptualize what that would look like with the verbal description alone.
The article appears to have described the free monad + interpreter pattern, that is, each business-logic statement doesn't execute the action (as a verb), but instead constructs it as a noun and slots it into some kind of AST. Once you have an AST you can execute it with either a ProdAstVisitor or a TestAstVisitor which will carry out the commands for real.
More specific to your question, it sounds like the pattern matching you mentioned is choosing between Test.ReadFile and Test.WriteFile at each node of the AST (not between Test.ReadFile and Prod.ReadFile.)
I think the Haskell community turned away a little from free monad + interpreter when it was pointed out that the 'tagless final' approach does the same thing with less ceremory, by just using typeclasses.
> I’d have liked to see the use of dependency injection via the effects system expanded upon.
I'm currently doing DI via effects, and I found a technique I'm super happy with:
At the lowest level, I have a bunch of classes & functions which I call capabilities, e.g
FileOps (readTextFile, writeTextFile, ...)
Logger (info, warn, err, ...)
Restful (postJsonBody, ...)
At the next level up I have classes & functions which can know about the business (and the lower level capabilities)
StoredCommands (fetchStoredCommands) - this uses the 'Restful' capability above to construct and send a payload to our business servers.
I associate CliApp to all its actual implementations (low-level and mid-level) using type classes:
instance FileOps CliApp where
readTextFile = readTextFileImpl
writeTextFile = writeTextFileImpl
...
instance Logger CliApp where
info = infoImpl
warn = warnImpl
err = errImpl
...
instance StoredCommands CliApp where
fetchStoredCommands = fetchStoredCommandsImpl
...
I can create a CliTestApp which has a different set of bindings, e.g.
instance Logger CliTestApp where
info msg = -- maybe store message using in-memory list so I can assert on it?
The low-level prod code (capabilites) are allowed to do IO, as signaled by the MonadIO in the type sig:
readTextFileImpl :: MonadIO m => FilePath -> m (Either String Text)
readTextFileTest :: Monad m => FilePath -> m (Either String Text)
Another way of looking at it is, if I invent a new capability (e.g. Caching) and start calling it from my business logic, the CliTestApp pointing at that same business logic will compile-time error that it doesn't have its own Caching implementation. If I try to 'cheat' by wiring the CliTestApp to the prod Caching (which would make my test cases non-deterministic) I'll get another compile-time error.
Would it work in OCaml? Not sure, the article says:
> Currently, it should be noted that effect propagation is not tracked by the type system
F# has FuncUI - based on Avalonia. All just possible because of the ecosystem.
Recovered typeaholic here. I still occasionally use OCaml and I primarily wrote F# and Haskell for years. I've been quite deep down the typing rabbit hole, and I used to scorn at dynamically typed languages.
Now I love dynamic typing - but not the Python kind - I prefer the Scheme kind - latent typing. More specifically, the Kernel[1] kind, which is incredibly powerful.
> I think the negative reputation of static type checking usually stems from a bad experience.
I think this goes two ways. Most people's experience with dynamic typing is the Python kind, and not the Kernel kind.
To be clear, I am not against static typing, and I love OCaml - but there are clear cases where static typing is the wrong tool - or rather, no static typing system is sufficient to express problems that are trivial to write correctly with the right dynamic types.
Moreover, some problems are inherently dynamic. Take for example object-capabilities (aka, security done right). Capabilities can be revoked at any time. It makes no sense to try and encode capabilities into a static type system - but I had such silly thoughts when I was a typeaholic, and I regularly see people making the same mistake. Wouldn't it be better to have a type system which can express things which are dynamic by nature?
And this is my issue with purely statically typed systems: They erase the types! I don't want to erase the types - I want the types to be available at runtime so that I can do things with them that I couldn't do at compile time - without me having to write a whole new interpreter.
My preference is for Gradual Typing[2], which lets us use both worlds. Gradual typing is static typing with a `dynamic` type in the type system, and sensible rules for converting between dynamic and static types - no transitivity in consistency.
People often mistake gradual typing with "optional typing" - the kind that Erlang, Python and Typescript have - but that's not correct. Those are dynamic first, with some static support. Gradual typing is static-first, with dynamic support.
Haskell could be seen as Gradual due to the presence of `Data.Dynamic`, but Haskell's type system, while a good static type system, doesn't make a very good dynamic type system.
Aside, my primary language now is C, which was the first language I learned ~25 years ago. I regressed! I came back to C because I was implementing a gradually typed language and F#/OCaml/Haskell were simply too slow to make it practical, C++/Rust were too opinionated and incompatible with what I want to achieve, and C (GNU dialect) let me have almost complete control over the CPU, which I need to make my own language good enough for practical use. After writing C for a while I learned to love it again. Manually micro-optimizing with inline assembly and SIMD and is fun!
Could you elaborate on the difference? I was under the impression that "latent typing" just means "values, not variables, have types", which would make Python (without type annotations) latently typed as well.
I'm know .NET in and out, so I might be biased. Most of the boring parts have multiple good solutions that I can pick from. I don't have to spend time on things that are not essential to the problem I actually want to solve.
I've used F# professionally for multiple years and maintain a quite popular UI library written in it. But even with .NET there still are gaps because of the smaller F# language ecosystem. Not everything "just works" between CLR languages - sometimes it's a bit more complicated.
The main point I'm trying to make is that going off the beaten path (C#) for example also comes with a cost. That cost might or might not be offset by the more expressive language. It's important to know this so you are not surprised by it.
With OCaml it's similar I'd say. You get a really powerful language, but you're off the beaten path. Sure, there are a few companies using it in production - but their use case might be different than yours. On Jane Streets Threads and Signals podcast they often talk about their really specific use cases.
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