A better build system for OCaml • Hacker News Board

Re: A better build system for OCaml

#151

Post by n144q » Fri, Jan 31, 2025, 1:23 PM UTC

giraffe_lady wrote: post #45

n144q wrote: 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 do! Their standard lib replacement was used on the project where I originally learned ocaml, so I have just always used it. You have to be fairly sophisticated at reading fn signatures to find things sometimes but otherwise no complaints with it. It has some very nice features too for example convert functions to/from sexps for all base types can save you a ton of time if you know it's there and plan for it. I've u…

Thanks! The "depends on an undocumented thing" happens quite often for such projects from companies, and is enough to hold people back -- in a company where a third party library requires approval, such issues mean that a fix could take a while before it is available internally, which could delay your own work etc. A lot of this probably comes down to the ecosystem -- not enough people are using these things to discover them early.

Re: A better build system for OCaml

#152

Post by Majromax » Fri, Jan 31, 2025, 1:23 PM UTC

robocat wrote: post #133

triyambakam wrote: post #47

Earlier quoted context omitted.

Very interesting footnote system. Is it just for fun and aesthetic or have a deeper origin or purpose?

the Chicago Manual of Style suggests this order: ⃰ (asterisk) † (dagger) ‡ (double dagger) § (section mark) ‖ (parallels) # (hash) (Hard to present glyphs that would actually be used in print - I've chosen what I think is close - but they are not that close because wrong font)

Compose key shenanigans can make such typesetting significantly easier. That's built-in on Linux/X, but there are also easy solutions for Windows systems.

Re: A better build system for OCaml

#153

Post by dgfitz » Fri, Jan 31, 2025, 1:29 PM UTC

philipwhiuk wrote: post #139

db48x wrote: post #87

Earlier quoted context omitted.

That’s such an obnoxious tactic. It’s basically saying “Your point is invalid unless you can cut this Gordian Knot on the spur of the moment in an internet comment!”

It's less bad than the ill informed Dunning-Kruger opinion it rebuts.

Don’t worry Phillip, ignoring the bit where it isn’t a rebuttal at all, I know I’m not a smart person. That’s why I like simple builds!

Re: A better build system for OCaml

#154

Post by cmrdporcupine » Fri, Jan 31, 2025, 1:35 PM UTC

eru wrote: post #121

cmrdporcupine wrote: post #49

Earlier quoted context omitted.

It's funny because the thing that always turned me off from Haskell was that it feels like a stream of whitespace and identifies without good visual cues as to structure. I'm sure once you get the zen of it, it's fine. Like Lisp, I guess, you learn to think in its structure. But looking at a screenful of Haskell to me is intimidating. Of the bunch I found SML/NJ to be the most readable.

The whitespace is the visual cue. But in any case, you can use curly braces and semicolons in Haskell just fine. You can also write your Haskell like Lisp, and add lots of parens everywhere, and use all operators in prefix-form.

Well there's apparently a not insignificant amount of Haskell at the new job I'm starting in a week, so I guess I'll see how I fare with it.

Re: A better build system for OCaml

#155

Post by eadmund » Fri, Jan 31, 2025, 1:48 PM UTC

feznyng wrote: post #70

gpderetta wrote: post #18

Earlier quoted context omitted.

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

Xmake uses lua if you want to give it a try.

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 …

Re: A better build system for OCaml

#156

Post by IshKebab » Fri, Jan 31, 2025, 1:58 PM UTC

tombert wrote: 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.

I dunno if anyone really doubted HM, functional programming could work. I've written a bit of OCaml and apart from the bad syntax (code very easily becomes a word soup) it's not especially different to other programming languages, just more convenient sometimes.

I think it's purity that actually is a big difference, but OCaml isn't pure.

Re: A better build system for OCaml

#157

Post by lotsofpulp » Fri, Jan 31, 2025, 2:04 PM UTC

n4r9 wrote: post #134

eru wrote: post #116

Earlier quoted context omitted.

Actually, not. These market makers are often prop shops. That means they use their own fund (prop = proprietary) to do the trading. They can do that because they don't need much capital to run. So the story here is that over the last twenty years they stole the lunch from the traditional market makers like eg banks. Of course, they got rich in the process. But they started from relatively modest means, compared to th…

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.

Re: A better build system for OCaml

#158

Post by be_erik » Fri, Jan 31, 2025, 2:25 PM UTC

coder543 wrote: post #60

blobbers wrote: post #26

Earlier quoted context omitted.

They likely mean 'generally used with other languages'. make is an example.

Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".

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.

Re: A better build system for OCaml

#159

Post by coder543 » Fri, Jan 31, 2025, 2:28 PM UTC

be_erik wrote: post #158

coder543 wrote: post #60

Earlier quoted context omitted.

Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".

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.

Re: A better build system for OCaml

#160

Post by dumah » Fri, Jan 31, 2025, 2:32 PM UTC

coder543 wrote: post #60

blobbers wrote: post #26

Earlier quoted context omitted.

They likely mean 'generally used with other languages'. make is an example.

Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".