Evolving the OCaml Programming Language (2025) [pdf] • Hacker News Board

Re: Evolving the OCaml Programming Language (2025) [pdf]

#31

Post by alabhyajindal » Fri, Sep 05, 2025, 12:31 PM UTC

rwmj wrote: post #30

alabhyajindal wrote: post #18

Earlier quoted context omitted.

This is not a direct comment on compiler development but on industrial projects in general: how do you begin contributing to something that is so large? What should a beginner in compiler development, someone who has written a few compilers of their own, do to get involved in a project such as OCaml? I understand this issue is not specific to compilers, but is faced by any sufficiently large project. Still, I think i…

(I think this advice applies to most large open source projects) Make sure you have installed and are using the software. Ideally you'd have an ongoing interest in it because it's something you use regularly (whether personally or for work). Read first, especially the documentation, guidelines to contributing, mailing lists / Github issues / however else the upstream maintainers engage with each other. Start small. A…

Thank you - I appreciate it!

Re: Evolving the OCaml Programming Language (2025) [pdf]

#32

Post by debugnik » Fri, Sep 05, 2025, 12:47 PM UTC

aguluman wrote: post #26

debugnik wrote: post #15

Earlier quoted context omitted.

My impression is that most people, as in a majority, aren't using Jane Street's Base and Core. Maybe some or even many , but not most , and specially not in the FOSS ecosystem. I think this idea comes from so many learning materials using their libs, you feel kind of funneled towards them at the start. But yes, the standard library has added many helper functions that were sorely needed during the last few years, and…

Is stdlib the original then base and core are extensions?

Yes, although they're replacements more than extensions. Stdlib is OCaml's builtin standard library, Base is Jane Street's lightweight replacement of Stdlib (although the most basic types are compatible), and Core is Jane Street's full standard library extending Base.

There's nothing inherently wrong with them, aside from their API being unstable, but they're an opinionated wedge in an ecosystem already lacking the cohesion of newer languages.

Re: Evolving the OCaml Programming Language (2025) [pdf]

#33

Post by StopDisinfo910 » Fri, Sep 05, 2025, 1:36 PM UTC

sidkshatriya wrote: post #10

kcsrk wrote: post #4

Earlier quoted context omitted.

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 ec…

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 t…

> 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.

Re: Evolving the OCaml Programming Language (2025) [pdf]

#34

Post by ux266478 » Fri, Sep 05, 2025, 3:29 PM UTC

debugnik wrote: post #23

kubb wrote: post #11

For people using OCaml, there’s one thing that kinda discourages me in it, that is exceptions as part of the API in the standard library. Because exceptions aren’t checked, this effectively means that a language designed for type safety has as much type safety as python, because it’s very easy to forget handling something, and get runtime errors. How do you deal with this day to day? I assume it’s impossible to just…

> as much type safety as python There's no type unsafety from unchecked exceptions, because uncaught exceptions are not unsound. Even Haskell has them (error and undefined), because from a theoretical standpoint they're equivalent to reaching an infinite loop. (Now, recovering from an exception isn't unsound either, but it might mess with your usual mutable invariants.) In more practical terms, concerning overall cor…

I don't think Haskell is a good language to model our idea of error handling off of. It's one of many bugbears I have with that language, that it uses the Maybe monad as an error type. It technically works, but doesn't provide a meaningful distinction between "This function might not return anything, and this is defined behavior" and "This function has a singularity". MonadError exists, but I can't think of anywhere it shows up without digging deep into dragon caves of the compiler. Everything a normal user is going to touch will deal exclusively in Maybes.

I'm not a fan of Rust as a language for many reasons, but I will give it credit for making proper usage of the Result monad. They could have abused Option the same way Haskell abuses Maybe, but they didn't.

Re: Evolving the OCaml Programming Language (2025) [pdf]

#35

Post by debugnik » Fri, Sep 05, 2025, 4:37 PM UTC

ux266478 wrote: post #34

debugnik wrote: post #23

Earlier quoted context omitted.

> as much type safety as python There's no type unsafety from unchecked exceptions, because uncaught exceptions are not unsound. Even Haskell has them (error and undefined), because from a theoretical standpoint they're equivalent to reaching an infinite loop. (Now, recovering from an exception isn't unsound either, but it might mess with your usual mutable invariants.) In more practical terms, concerning overall cor…

I don't think Haskell is a good language to model our idea of error handling off of. It's one of many bugbears I have with that language, that it uses the Maybe monad as an error type. It technically works, but doesn't provide a meaningful distinction between "This function might not return anything, and this is defined behavior" and "This function has a singularity". MonadError exists, but I can't think of anywhere…

I was just using Haskell's reputation to push back on the "as much type safety as python" hot take.

> [Haskell] doesn't provide a meaningful distinction between "This function might not return anything, and this is defined behavior" and "This function has a singularity"

I think Haskellers should fear divergence less, or push for SPARK-like static checking. In OCaml, the current trend would be to represent "not return anything" as None; and "has a singularity" by raising Invalid_argument or similar when the singularity check was considered a precondition, or returning Error (or an equivalent variant) for expected inputs.

Usage of Result in OCaml is also growing, thankfully. It's part of the stdlib, and we can use binding operators (let* foo = result) to do the same as ? in Rust (or let! in F#). OCaml 5.4 is even adding a Result.Syntax module so we can just open it instead of defining (let*) ourselves.

On the other hand, Result doesn't give us backtraces, and composes badly with other combinators or imperative flow. In my current project I'm instead giving a try to an effectul result_scope/get_ok API, which composes better.

Re: Evolving the OCaml Programming Language (2025) [pdf]

#36

Post by spit2wind » Fri, Sep 05, 2025, 5:09 PM UTC

sidkshatriya wrote: post #12

sidkshatriya wrote: post #10

Earlier quoted context omitted.

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 t…

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…

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?

Re: Evolving the OCaml Programming Language (2025) [pdf]

#37

Post by yawaramin » Fri, Sep 05, 2025, 6:38 PM UTC

kubb wrote: post #11

For people using OCaml, there’s one thing that kinda discourages me in it, that is exceptions as part of the API in the standard library. Because exceptions aren’t checked, this effectively means that a language designed for type safety has as much type safety as python, because it’s very easy to forget handling something, and get runtime errors. How do you deal with this day to day? I assume it’s impossible to just…

Every mainstream language has exceptions. Everyone knows how to use exceptions. They're easy to use and get the job done. OCaml suffers no type safety issues from the use of exceptions. It also has option and result types so people who need more control flow can use those. The OCaml standard library typically uses exceptions for real exceptional conditions like eg trying to access a key that doesn't exist in a map. Even Rust has panics which are basically exceptions.

You criticized Haskell as not a great example of error handling. Well, Erlang/Elixir also have exceptions, and they are considered the industry leader in error recovery.

Exceptions are actually fine, it doesn't really take much to install handlers which take care of catching, logging, telemetry, re-raising etc. They mostly get a bad rep because of the latest fashions in the PL space.

Re: Evolving the OCaml Programming Language (2025) [pdf]

#38

Post by debugnik » Fri, Sep 05, 2025, 8:06 PM UTC

spit2wind wrote: post #36

sidkshatriya wrote: post #12

Earlier quoted context omitted.

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…

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?

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.

Re: Evolving the OCaml Programming Language (2025) [pdf]

#39

Post by nitnelave » Fri, Sep 05, 2025, 8:23 PM UTC

rwmj wrote: post #30

alabhyajindal wrote: post #18

Earlier quoted context omitted.

This is not a direct comment on compiler development but on industrial projects in general: how do you begin contributing to something that is so large? What should a beginner in compiler development, someone who has written a few compilers of their own, do to get involved in a project such as OCaml? I understand this issue is not specific to compilers, but is faced by any sufficiently large project. Still, I think i…

(I think this advice applies to most large open source projects) Make sure you have installed and are using the software. Ideally you'd have an ongoing interest in it because it's something you use regularly (whether personally or for work). Read first, especially the documentation, guidelines to contributing, mailing lists / Github issues / however else the upstream maintainers engage with each other. Start small. A…

Also, of course, talk to people. Pitch your PR idea before writing it, so you can avoid hearing "oh, there's a much simpler way" or "we can never merge this approach because of X"

Re: Evolving the OCaml Programming Language (2025) [pdf]

#40

Post by lambda_foo » Sat, Sep 06, 2025, 12:01 AM UTC

rwmj wrote: post #7

kcsrk wrote: post #2

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,…

I'm at a conference at the moment so can't give a lengthy answer, but I'm the maintainer of virt-v2v, one large open source OCaml project (large if you include all the dependencies) which generates actual multi-millions in annual revenue, but is often overlooked in all this discussion of the OCaml ecosystem. Glad to talk by email some time. [BTW we currently have open positions for two developers]

Thanks for sharing, I had no idea about this project.

Could you share some more details about where this project is used? Links to those open positions for OCaml developers would be interesting too, not for myself :-)