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

A better build system for OCaml

blog.janestreet.com

Post reply on HN
Print view View original

71–80 of 219 posts

Re: A better build system for OCaml

#71

Post by kevin_thibedeau »

cmrdporcupine wrote: post #48
kevin_thibedeau wrote: post #32

Earlier quoted context omitted.

The ideas embodied in modern target-oriented CMake are worthwhile. It's all hobbled by a dreadful script language but that could be improved with sufficient motivation.

It's hobbled not just by that but by the fact that it's not the thing doing the building. It's a build system for build systems, and suffers from brittleness and confusion as a result.

Make, in all its various implementations, is far more brittle than CMake. Ninja requires a meta-build tool like CMake.

Re: A better build system for OCaml

#72

Post by almostgotcaught »

dgfitz wrote: post #51
almostgotcaught wrote: post #50

Earlier quoted context omitted.

so simple huh? since you fancy yourself an architect can you let me know how we might fix the architecture of https://github.com/llvm/llvm-project such that CMake is no longer needed?

Not in a glib response, no.

okay can you at least tell me how the architecture of https://github.com/llvm/llvm-project is "bad"?

Re: A better build system for OCaml

#73

Post by ahartmetz »

queuebert wrote: post #41
tom_ wrote: post #31

Earlier quoted context omitted.

I don't mind CMake. It's awful, but I'm already using C or C++, so the bar is set pretty low. It does do a few things right, and at least some of the things it does wrong are manageable. I'll eat at least a bit of shit if it means I can get more than one platform's-worth of build process out of a single set of human-editable configuration files.

Have you tried meson? I used it once many years ago, and it seemed slightly better.

Meson's approach to simplicity is if you need anything nontrivial, you simply add it to Meson itself. In CMake, you can script it in more cases.

Re: A better build system for OCaml

#74

Post by fuzztester »

udev4096 wrote: post #68
whydid wrote: post #65

Earlier quoted context omitted.

Grass is always greener my friend. Many jobs in finance are updating 20 year old Java code, or figuring out new ways to load data in and out of Excel files for custom reporting.

OP should've been more specific. HFT firms, not any other finance companies, probably have a lot more exciting work due to the nature of reducing latency using all sorts of novel techniques. I wonder if they disable all the fancy exploit mitigation protection in linux kernel just for a tiny performance hit

some use a fork of rust with borrow checking disabled.

go fish

Re: A better build system for OCaml

#75

Post by shepherdjerred »

fuzztester wrote: post #74
udev4096 wrote: post #68

Earlier quoted context omitted.

OP should've been more specific. HFT firms, not any other finance companies, probably have a lot more exciting work due to the nature of reducing latency using all sorts of novel techniques. I wonder if they disable all the fancy exploit mitigation protection in linux kernel just for a tiny performance hit

some use a fork of rust with borrow checking disabled. go fish

Isn’t borrow checking only compile time?

Re: A better build system for OCaml

#76

Post by fulafel »

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.

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.

Re: A better build system for OCaml

#78

Post by ofrzeta »

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

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

Why does Mercury not use ... Mercury? https://mercurylang.org/

Re: A better build system for OCaml

#79

Post by emoII »

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.

What do you mean? Afaik the type system does not affect run time speed, it’s just static analysis

Re: A better build system for OCaml

#80

Post by n4r9 »

udev4096 wrote: post #68
whydid wrote: post #65

Earlier quoted context omitted.

Grass is always greener my friend. Many jobs in finance are updating 20 year old Java code, or figuring out new ways to load data in and out of Excel files for custom reporting.

OP should've been more specific. HFT firms, not any other finance companies, probably have a lot more exciting work due to the nature of reducing latency using all sorts of novel techniques. I wonder if they disable all the fancy exploit mitigation protection in linux kernel just for a tiny performance hit

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.
Post reply on HN