Most active commenters
  • sidkshatriya(3)
  • StopDisinfo910(3)

←back to thread

Evolving the OCaml Programming Language (2025) [pdf]

(kcsrk.info)
157 points matt_d | 13 comments | 05 Sep 25 00:05 UTC | HN request time: 0.602s | source | bottom
Show context
kcsrk ◴[05 Sep 25 04:03 UTC] No.45134878[source]▶
I am the author of the talk here o/.

This talk is a _subjective_ take on how the OCaml programming language evolves, based on my observations over the last 10 years I've been involved with it. My aim/hope is to demystify the compiler development process and the tradeoffs involved and encourage more developers to take a shot at contributing to the OCaml compiler.

Happy to answer questions, but also, more importantly, hear your comments and criticisms around the compiler development process, ideas to make it more approachable, etc.

replies(4): >>45135115 #>>45135373 #>>45136851 #>>45145616 #
ofrzeta ◴[05 Sep 25 04:58 UTC] No.45135115[source]▶
To be honest the story about the two closed PRs for dynamic arrays doesn't really inspire contributions :)
replies(3): >>45135152 #>>45135208 #>>45135483 #
kcsrk ◴[05 Sep 25 05:05 UTC] No.45135152[source]▶
You are right that the dynamic arrays story does not read like a straightforward “how to inspire contributions.” But part of what I wanted to do in the talk was to show things as they actually unfolded. In OCaml compiler development, there is a very strong emphasis on correctness and long-term stability. That can make contributions, especially to core language features, feel harder than they might in faster-moving ecosystems.

The dynamic arrays case is a good illustration. What began as a small PR grew into years of design iterations, debates about representation, performance, and multicore safety, and eventually a couple of thousand lines of code and more than 500 comments before it landed. From one perspective, that looks discouraging. From another, it shows the weight we place on getting things right, because once a feature ships, it is very hard to undo.

That tension, between wanting to be open and encouraging contributions but also needing to protect stability, is something I think we should be talking about openly. My hope is that by making the process more visible we can demystify it and help contributors understand not just what happened, but why.

replies(2): >>45135698 #>>45136227 #
1. sidkshatriya ◴[05 Sep 25 08:18 UTC] No.45136227[source]▶
I think this is the tension in most software. If you want to have excellent and correct software it will take time.

And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever.

But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the time OCaml "catches up" the field of programming languages has moved far ahead. So OCaml always remains the Jack of all trades and the master of none (IMHO).

I like the direction OxCaml is taking. But the problem is that no one has another 10 years to see its learnings get folded back into OCaml. There is a real chance that OxCaml may diverge so much that it becomes impractical to merge it into OCaml. Flambda2 is another great piece of software that may also take a long time to come into OCaml proper.

So I feel that things need to be "speeded up" if OCaml has to become a bigger ecosystem. You can see that some big projects are moving away from OCaml -- facebook for instance used to have their python typechecker in OCaml. Their new one, pyrefly is in Rust. This could be an isolated story, no doubt.

replies(4): >>45136296 #>>45136521 #>>45137209 #>>45138413 #
2. sidkshatriya ◴[05 Sep 25 08:30 UTC] No.45136296[source]▶
Now OCaml values adding features carefully to the language so that there is no future regret. But being slow and conservative has _not_ minimized regret. The "O" in OCaml i.e. Objects (and Classes) is almost ignored nowadays. Janestreet, a large industrial user seems to be actively against using the "O" part of OCaml.

So here we have gotten the worst of both worlds -- a language that is evolving slowly and a language that has large features that are almost soft discouraged. My primary language is Rust and not OCaml (mostly dabble in OCaml) so I may not fully know what I'm talking about when it comes to OCaml.

replies(3): >>45137054 #>>45137152 #>>45140927 #
3. rwmj ◴[05 Sep 25 09:06 UTC] No.45136521[source]▶
OCaml is doing just fine, thanks.
4. debugnik ◴[05 Sep 25 10:33 UTC] No.45137054[source]▶
> and a language that has large features that are almost soft discouraged

It's literally just objects, one large (and early!) feature. Arguably too large compared to the rest of the language: first-class modules or polymorphic variants can handle most of their use cases while being much simpler, and faster than the existing class system. (Objects and object types without the actual classes are maybe ok.)

The only other controversial feature I can think of is Seq and that's just because it can be allocation-heavy. Then again ordinary OCaml lists are not much cheaper (thankfully immutable arrays are already in for 5.4).

5. jact ◴[05 Sep 25 10:49 UTC] No.45137152[source]▶
The distaste for the OCaml object system is mostly misplaced in the community. While first class modules can mostly replace them — sometimes you really need open recursion. Object types are also a very useful feature used by core libraries.
replies(2): >>45137417 #>>45137558 #
6. ◴[05 Sep 25 11:01 UTC] No.45137209[source]▶
7. ◴[05 Sep 25 11:38 UTC] No.45137417{3}[source]▶
8. StopDisinfo910 ◴[05 Sep 25 12:01 UTC] No.45137558{3}[source]▶
Ocaml objects are structurally typed which can also be very nice. They definitely have their place.
9. StopDisinfo910 ◴[05 Sep 25 13:36 UTC] No.45138413[source]▶
> By the time OCaml "catches up" the field of programming languages has moved far ahead.

Hard to reconcile with the fact that Ocaml had 90% of the features people like in Rust today twenty years ago, a module system which is still better than Haskell, and is currently implementing a full effect system.

It still pretty much ahead of every mainstream languages.

replies(1): >>45147294 #
10. spit2wind ◴[05 Sep 25 17:09 UTC] No.45140927[source]▶
Interesting. I'm still working my way through Correct+Efficient+Beautiful. My takeaway so far has been that Modules _are_ the "O" part of OCaml. I guess there's something more "traditionally" an object? Does that mean there were modules in Caml (or whatever the predecessor was) and it was decided classes might be a good feature to add?
replies(1): >>45143009 #
11. debugnik ◴[05 Sep 25 20:06 UTC] No.45143009{3}[source]▶
Yes, the O in OCaml extends the type system with structurally typed objects and a classic OOP class system.

They're conceptually nice, specially the in-place object syntax, but the class syntax feels tacked on and the overall implementation is very naive compared to a proper OOP runtime like CLR/JVM/JS.

I suggest reaching for them only when first-class modules aren't enough (i.e. you need open recursion). Even then you could sometimes get away with polymorphic variant constraints, but that's admittedly harder to read and understand.

12. sidkshatriya ◴[06 Sep 25 07:18 UTC] No.45147294[source]▶
> a module system which is still better than Haskell

The module system though powerful is quite awkward and verbose. I personally prefer adhoc polymorphism (class/instance in Haskell, trait/implementation in Rust). That is really missed in OCaml and is likely to be missing for the next few years even though there have been (stalled) efforts like Modular implicits in the past.

Haskell and Scala seem to have many features lacking in OCaml. Some of those features are excessive I'll admit and OCaml can argue that it is more minimalistic (which is also useful).

Yes, effects are definitely a cutting edge feature in OCaml. But they are untyped which is a big limitation I would say.

TL;DR -- OCaml does many things well. It's a good language. My main point is that the language needs to speed up its pace of evolution. OCaml's lunch is being eaten up by lower level and performance oriented languages like Rust. At the higher level it is being squeezed by Lean, Haskell, Fstar etc.

replies(1): >>45150725 #
13. StopDisinfo910 ◴[06 Sep 25 16:34 UTC] No.45150725{3}[source]▶
> The module system though powerful is quite awkward and verbose.

Deeply disagree. It’s a lot easier to use and reason about that type classes. You can use Haskell if that’s what you want anyway. I’m glade Ocaml isn’t Haskell.

> Yes, effects are definitely a cutting edge feature in OCaml. But they are untyped which is a big limitation I would say.

APersonally I think it’s an insignificant limitation for a feature existing approximately nowhere else. Anyway I think we have safely killed your initial argument that Ocaml was somehow lagging behind.