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

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

#21

Post by Quekid5 » Fri, Sep 05, 2025, 10:57 AM UTC

aseipp wrote: post #8

ofrzeta wrote: post #3

Earlier quoted context omitted.

To be honest the story about the two closed PRs for dynamic arrays doesn't really inspire contributions :)

I think it's just the nature of the beast, in this case. Serious "industrial" implementations of a programming language might stick around for a long time, and breaking things a lot can mar the appeal; getting it right the first time pays off in that case. I think the acceptance threshold can be much lower in other kinds of tooling. "It is what it is", so to speak.

Add a sane deprecation process and this is much less of an issue -- see e.g. the Java language. Sure, it's not ideal to have multiple implementations of the 'same' data structure (if a better way is found, say)... but at least you aren't stalling everything and causing API interop issues for years and years.

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

#22

Post by [deleted] » Fri, Sep 05, 2025, 11:01 AM 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…

[deleted]

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

#23

Post by debugnik » Fri, Sep 05, 2025, 11:09 AM 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…

> 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 correctness, OCaml has been adding option-returning variants of those functions, so most exceptions raised from the stdlib nowadays are much more likely to be intended by the author.

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

#24

Post by johnisgood » Fri, Sep 05, 2025, 11:19 AM 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…

Your comment does not make much sense even if it is true.

Factor (Forth-like language) implements even its own ":" (defines a word, i.e. a function) using the language itself, it is not builtin, same with "if", and so forth. Thus, "MEMO:" or locals[1] ("::") being implemented as a library does not mean it is a bad thing, on the contrary, in the case of Factor, it makes it quite powerful. The object system is entirely implemented in Factor, too. "Large chunks of functionality are not part of the core language, they are in just as library".[2]

And to compare OCaml's type system to Python's is straight out absurd.

[1] Locals are entirely implemented in Factor, too, which is only about ~500 lines of code. It is not part of the core language, and on top of that, there is no performance penalty whatsoever!

[2] See more here: https://www.youtube.com/watch?v=f_0QlhYlS8g.

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

#25

Post by [deleted] » Fri, Sep 05, 2025, 11:38 AM UTC

jact wrote: post #20

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…

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.

[deleted]

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

#26

Post by aguluman » Fri, Sep 05, 2025, 11:44 AM UTC

debugnik wrote: post #15

zerr wrote: post #14

I remember the go to alternative "standard" library was being developed by some bank from Wall Street. Is it still the case? i.e. do most people still use that 3rd party lib or did the real standard library evolve since then?

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?

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

#27

Post by kcsrk » Fri, Sep 05, 2025, 11:58 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]

It was overlooked because I didn't know!

Great to hear about virt-v2v. I will reach out to you by email.

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

#28

Post by rs186 » Fri, Sep 05, 2025, 12:00 PM UTC

zerr wrote: post #14

I remember the go to alternative "standard" library was being developed by some bank from Wall Street. Is it still the case? i.e. do most people still use that 3rd party lib or did the real standard library evolve since then?

That's my concern for even adopting OCaml for my hobby projects. Poking around Jane Street's "alternative" standard library does not give me much confidence about its state. Just the fact that there are Core and Base isn't encouraging. If I ever use OCaml in a project, I want to spend time getting things done, not looking for implementations or writing code myself (unless I am really in a mood to do so).

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

#29

Post by StopDisinfo910 » Fri, Sep 05, 2025, 12:01 PM UTC

jact wrote: post #20

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…

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.

Ocaml objects are structurally typed which can also be very nice. They definitely have their place.

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

#30

Post by rwmj » Fri, Sep 05, 2025, 12:28 PM UTC

alabhyajindal wrote: post #18

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

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. Actually a great place is just to go and fix spelling mistakes and typos in documentation, code, comments, etc. Follow the guidelines for contributing to the letter, even if they appear over-complicated at first.

After you've engaged with small patches, build up. Look through their issues and (since you're using the software every day) find something that is an "itch" that you want to "scratch", and attempt to fix that.

I don't really need to go further because either at some point in this process you'll have become discouraged (for good or bad reasons), or you'll have found your community and will want to contribute more and more.