Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evolving the OCaml Programming Language (2025) [pdf]

kcsrk.info

Post reply on HN
Print view View original

41–50 of 52 posts

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

#41

Post by hoppp »

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

Is there a video for the talk? The link is just pdf and I would love to hear it

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

#42

Post by rwmj »

lambda_foo wrote: post #40
rwmj wrote: post #7

Earlier quoted context omitted.

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 :-)

For converting VMs that run on VMware to run on KVM. After Broadcom purchased VMware a couple of years ago & raised prices (in some cases up to 10x), lots and lots of businesses are desperate to leave VMware. The open positions can be found on the Red Hat website if you search roles for "virt-v2v".

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

#43

Post by sidkshatriya »

StopDisinfo910 wrote: post #33
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…

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

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

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

#44

Post by StopDisinfo910 »

sidkshatriya wrote: post #43
StopDisinfo910 wrote: post #33

Earlier quoted context omitted.

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

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

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

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

#46

Post by yawaramin »

rwmj wrote: post #42
lambda_foo wrote: post #40

Earlier quoted context omitted.

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 :-)

For converting VMs that run on VMware to run on KVM. After Broadcom purchased VMware a couple of years ago & raised prices (in some cases up to 10x), lots and lots of businesses are desperate to leave VMware. The open positions can be found on the Red Hat website if you search roles for "virt-v2v".

Found this one: https://redhat.wd5.myworkdayjobs.com/en-US/jobs/details/Prin...

No mention of OCaml though.

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

#47

Post by aguluman »

rs186 wrote: post #28
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).

Hi there, I use OCaml in my hobby projects. You will get this done, if you experiments and find what works for you. Personally, I use Base and Stdlib. Its been enough for my 3 projects so far.

Don't know if this would be of value to you. You can check out my blog built with OCaml, its made from my custome static site generator. https://www.fearful-odds.rocks

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

#48

Post by akkad33 »

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

Rust also has exceptions aka panics

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

#49

Post by rwmj »

yawaramin wrote: post #46
rwmj wrote: post #42

Earlier quoted context omitted.

For converting VMs that run on VMware to run on KVM. After Broadcom purchased VMware a couple of years ago & raised prices (in some cases up to 10x), lots and lots of businesses are desperate to leave VMware. The open positions can be found on the Red Hat website if you search roles for "virt-v2v".

Found this one: https://redhat.wd5.myworkdayjobs.com/en-US/jobs/details/Prin... No mention of OCaml though.

Right, we don't mention it in the advert because doing so draws in a certain type of academic person that we don't want to hire. Also because the majority of the code is actually in other programming languages, and we can easily train up (eg.) an ace C coder in OCaml if we need to.

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

#50

Post by ux266478 »

akkad33 wrote: post #48
ux266478 wrote: post #34

Earlier quoted context omitted.

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'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 Rust also has exceptions aka panics

So does Haskell.
Post reply on HN