Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

1–10 of 219 posts

Re: A better build system for OCaml

#4
I have to respect Jane Street for proving that HM-typed functional programming can be production-ready and extremely fast when given enough love.

I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.

Re: A better build system for OCaml

#5
kinda surprising that it still makes sense to develop your own new build system, and then do the migration to it, instead of adopting an off-the-shelf one like buck2 (or bazel/etc...). Not saying that these fancy build tools are easy to adopt, but compared to building your own? is there something remarkable that makes dune much different?

Re: A better build system for OCaml

#6
I spent several years in Haskell land a while back, my first functional experience after Lisp.

Ocaml never clicked for me, I have a rare form of semicolon allergy and Haskell just looked a lot nicer to me.

But then I recently tried Reason and enjoyed it A LOT, so everything Ocaml is suddenly interesting.

Re: A better build system for OCaml

#7
They did an episode of Signals and Threads (Jane Street's technical podcast) about their build systems back in 2020¥. Highly recommended, as are the other episodes, especially The Future of Programming with Richard Eisenberg° and What is an Operating System? with Anil Madhavapeddy§.

¥https://signalsandthreads.com/build-systems/

°https://signalsandthreads.com/future-of-programming/

§https://signalsandthreads.com/what-is-an-operating-system/

Re: A better build system for OCaml

#8
post #5

kinda surprising that it still makes sense to develop your own new build system, and then do the migration to it, instead of adopting an off-the-shelf one like buck2 (or bazel/etc...). Not saying that these fancy build tools are easy to adopt, but compared to building your own? is there something remarkable that makes dune much different?

Without getting into any specifics of it - I'm sure there's people with much more experience with these tools who can comment - I'll point out that neither buck nor bzl existed when JS decided to start building their own tool in 2012. Bazel's first release was in 2015, Buck's was in 2013.

JS does have a bit of a NIH culture, but I'm not sure if that was really at play here. There just...weren't very many good build tools available at the time, particularly for a company using an unorthodox tech stack.

Re: A better build system for OCaml

#9
post #5

kinda surprising that it still makes sense to develop your own new build system, and then do the migration to it, instead of adopting an off-the-shelf one like buck2 (or bazel/etc...). Not saying that these fancy build tools are easy to adopt, but compared to building your own? is there something remarkable that makes dune much different?

I don't know ocaml particularly well but my understanding is that only with buck2 (of those mentioned) do you have a build system with the semantics to actually compile ocaml properly.

In particular I was under the impression one needed to be able to run ocamldep before hand (or compile twice) - buck2 can do this, bazel needs hacks iirc.

Re: A better build system for OCaml

#10
I respectfully have to disagree. As Fedora packager for OCaml packages, dune's configuration is yet another one-off, with a weird Lisp syntax, hard to understand, difficult to patch. I'd far rather people stuck to using more familiar Linux build systems. As an upstream OCaml developer, the whole thing falls down the minute you need to integrate other programming languages into your build (or OCaml code into a code base written in another language).

(This rant more or less equally applies to other language-specific build systems.)

Post reply on HN