Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

11–20 of 219 posts

Re: A better build system for OCaml

#11
post #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.

I loath autotools with a passion, and it's awkward to set it all up, but it handles OCaml code just fine. We use it for multi-language projects (including OCaml) like nbdkit & libguestfs.

Re: A better build system for OCaml

#12
I wonder if anyone has used Jane Street's open source OCaml libraries and tools for somewhat serious projects.

I took a brief look at these things, and my impression is that their stuff isn't "ready" for anyone outside Jane Street, even though they put a lot of effort in building the ecosystem and open source their code.

Re: A better build system for OCaml

#14
post #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.

> HM-typed functional programming

Mercury also uses Haskell for their backend https://mercury.com/

Re: A better build system for OCaml

#15
post #12

I wonder if anyone has used Jane Street's open source OCaml libraries and tools for somewhat serious projects. I took a brief look at these things, and my impression is that their stuff isn't "ready" for anyone outside Jane Street, even though they put a lot of effort in building the ecosystem and open source their code.

I tried to use their magic-trace tool but I get at least 4 differents crash when using it on trivial dotnet programs.

Re: A better build system for OCaml

#16
post #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 ba…

I haven't been doing much OCaml in recent years, but I do sometimes check in to see what's going on in OCaml-land, and it seems like dune is what everyone is using now - what are the alternatives?

Re: A better build system for OCaml

#17
post #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.

> HM-typed functional programming Mercury also uses Haskell for their backend https://mercury.com/

Also very cool!

I was fortunate enough to work at Jet.com before Walmart completely destroyed it, which was an F# shop. I really liked it, and I never really felt "limited" by it.

The stuff I was working on didn't have nearly the same requirements as high-frequency trading like Jane Street does though. I never did any super low-latency stuff with F#, so it's tough for me to say how well it fair with that kind of environment.

Re: A better build system for OCaml

#18
post #13

The only thing worse than a complex codebase is a complex build system. I think CMake is an abomination. “Hey go learn this new language to compile this other language!”

> CMake is an abomination. “Hey go learn this new language to compile this other language!”

"go learn this awful new language"

Re: A better build system for OCaml

#19
post #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 t…

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

But Dune started (according to this blog post) in 2016 and JS started seriously improving and adopting it last year. So to me Jenga sounds like a reasonable step in 2012, but pouring significant effort into migrating from Jenga to Dune (and improving Dune) in 2024 sounds more weird

Re: A better build system for OCaml

#20
post #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.

i wish the reason syntax was the main one
Post reply on HN