Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

171–180 of 219 posts

Re: A better build system for OCaml

#171

Earlier quoted context omitted.

Make is the common denominator in most projects I come across regardless of language. I see lots of frontend projects and certainly Go and Rust projects using Make quite often. Ironically many modern C/C++ projects use Cmake to generate Makefiles. If anything the inverse of your observation is mine.

Are those Makefiles doing anything more than calling "go build" and "cargo build"? Because if they're still using the language-specific build tools and dependency management systems, then I think you would find that the Fedora maintainer higher in this thread would not be any happier that there is a sugar coating of Make. That's not what they're asking for, based on other rants I've seen from Linux distro maintainers…

The barebones ones do exactly what you mentioned: simple calls to the canonical build tool.

The more complex ones at $JOB actually do some caching, dependency management, code generation, and compilation.

Re: A better build system for OCaml

#172

Earlier quoted context omitted.

He did write ‘awful,’ which is a fair description of the experience of writing Lua. I don’t mean that as an insult to Lua’s creators. They seem like really smart fellows. It’s just that the language is (to my eyes, with my background) viciously ugly. And 1-based arrays, of course, are evil. It has some neat ideas, though, and it is supposed to be very easy to integrate into a project. But man, that syntax …

1-based arrays are fully optional in Lua. You can use -2-indexed arrays instead, should you wish to.

Ah good old $[ in perl.

Re: A better build system for OCaml

#173
post #42
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.

“If your intention is to compile or interpret files as scripts, double semicolons can and should be avoided when writing in OCaml. Leaving them does not raise errors, but they are useless. The compiler tolerates them to allow copy-paste from UTop to a file without having to remove them.“ https://ocaml.org/docs/toplevel-introduction#loading-librari... https://reasonml.github.io/ looks cool, OCaml with javascript.

> https://reasonml.github.io/ looks cool, OCaml with javascript.

The Javascript-oriented part of ReasonML got forked to be its own language: Rescript. https://rescript-lang.org/

Re: A better build system for OCaml

#174
post #76
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.

Eh, this reads like damning with faint praise to me. Lots of robust and fast real world systems are in FP languages. Ocaml is estabilished and mature, far from "is it production ready?" category.

Not really meant to be "damning", I'm a pretty big functional programming advocate (I've spoken at the Lambda Days conference four times and the Clojure Conj once).

It feels like the trend right now is to bolt on one or two "functional libraries" into your "normal" language and pretend that that's the same as writing Haskell or Ocaml. People have actually expressed such sentiments to me because Java has the optional type and a "map" function for the Streams API. When I suggest writing something in a functional language, the response is always "it's too hard" or "we won't be able to hire for that", as if engineers are somehow unable to learn new things.

Re: A better build system for OCaml

#175

Earlier quoted context omitted.

He did write ‘awful,’ which is a fair description of the experience of writing Lua. I don’t mean that as an insult to Lua’s creators. They seem like really smart fellows. It’s just that the language is (to my eyes, with my background) viciously ugly. And 1-based arrays, of course, are evil. It has some neat ideas, though, and it is supposed to be very easy to integrate into a project. But man, that syntax …

I kind of agree, but it's still far better than CMake's custom language IMO.

I suspect that INTERCAL would be better than CMake's own language.

Re: A better build system for OCaml

#176
post #42

Earlier quoted context omitted.

“If your intention is to compile or interpret files as scripts, double semicolons can and should be avoided when writing in OCaml. Leaving them does not raise errors, but they are useless. The compiler tolerates them to allow copy-paste from UTop to a file without having to remove them.“ https://ocaml.org/docs/toplevel-introduction#loading-librari... https://reasonml.github.io/ looks cool, OCaml with javascript.

> https://reasonml.github.io/ looks cool, OCaml with javascript. The Javascript-oriented part of ReasonML got forked to be its own language: Rescript. https://rescript-lang.org/

you can, for now at least, still use reasonML with js_of_ocaml to compile to javascript if you like reason syntax but don't want to a more complicated relationship with the ocaml ecosystem (we use this for https://hazel.org)

Re: A better build system for OCaml

#177
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…

As a user of Linux, I wish Linux distributions would abandon their build systems which really only work well for C and maybe C++, and also only work on one platform (not even the whole of linux!) meaning that packaging has to be duplicated for every OS, and stuck to using more familiar language-specific build systems that work everywhere. (this rant more or less equally applies to all os-or-distro-specific build syst…

> [Distro-specific build systems are] probably the biggest barrier to me shipping software on Linux.

Don’t[1]. Ship source tarballs (or VCS tags).

I’ll grant that most distros’ build systems are antiquated and, in places, silly. (That includes Nixpkgs, first released 2006.) We could really use some fresh ideas there.

But they’re also not for you (or me) in your (or my) capacity as a software author. They’re there for a person who works on packaging software for, most of the time, a single distro, and their balance of complexity and flexibility is calibrated accordingly. One of the functions of that person is also to keep you honest and represent the interests of users before you, because they have more expertise than the users but not as much of an attachment to your software as you. The ecosystem is less healthy when the author tries to fill in for the packager.

“But then the users will come to my bugtracker to complain about bugs in patched versions!” Pre-Google, we used to have a solution for that: a configure option to set the bug reporting email, present in all GNU software. Nowadays it’s not clear what a good solution could be, but it does seem like, unfortunately, the author will have to maintain a table of packager contact information for the end users.

[1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

Re: A better build system for OCaml

#178
post #93
post #80

Earlier quoted context omitted.

Mother capitalism deems that our brightest young minds best serve humanity in two tasks. Keeping the public passively scrolling, and moving money at speed to make wealthy people more wealthy.

Is the problem with the system or with the minds? The minds that want to scroll are the same as the ones that make money on the scrolling, that made the scrolling itself, and that made the system we're in. Why is it that defeatist comments always focus on the capitalism part and not on anything else? I don't think it's perfect like we aren't perfect but unless you have some particular suggestion this type of comment…

> Why is it that defeatist comments always focus on the capitalism part and not on anything else

Because endless growth is the only reason these once fun spaces have been hyper focused to be as addictive and stressful as possible to the "whales" of scrolling. That's why, when their own internal reports say "people spend unhealthy time on our platform and it's making them unhappy," it gets passed up the chain of command and whittled down by internal incentives until it dies as an issue.

Individuals hold some blame, but to put most of it on them is to ignore what growth demands. You're supposed to doomscroll and engage and worry. That's the business model. Facebook is in the same business as Cigarettes and Casinos. When I see someone on an air tank playing slots, literally crying when they spend their last dollar, I will not waste my breath blaming them. Just like I won't blame the doomscroller, anxious that they need to stay "informed," who hasn't met the basic needs in their own life.

> The minds that want to scroll are the same as the ones that make money on the scrolling

No? Where are you getting this? I don't think the people guiding these companies want to spend 6 hours scrolling TikTok. This is not the way most people live their lives.

Re: A better build system for OCaml

#179
post #134

Earlier quoted context omitted.

Perhaps some start this way. But in terms of the general trend of talented engineers and mathematicians being sucked into this quant vortex, it is a matter of making wealthy people wealthier.

Automation in trading makes all investors wealthier via lower fees. Trading costs basically nothing nowadays, and that is because far fewer people are employed to do it. Obviously, the people who own the automation will want a cut of the rewards, like any other business.

Automation in trading != HFT algorithms

Obviously NASDAQ and electronic trading systems are a good innovation. But firms basically doing arbitrage or exploiting uneven network latency are not that economically productive.

Re: A better build system for OCaml

#180
post #140

Earlier quoted context omitted.

Maybe, but could you live with the fact that you're providing absolutely no value to the world? It always makes me sad when the greatest minds get gobbled up by these companies because they're creaming off the top of an enormously complex system they created.

As someone that used to work in this world I find this opinion of “no value” pretty bizarre. There’s a lot of value in efficient markets with high liquidity and low fees, which companies like JS make possible.

They've only been around for a short while so how could you know?

Let's see if they last at least a couple of centuries.

Post reply on HN