A better build system for OCaml • Hacker News Board

Re: A better build system for OCaml

#181

Post by cess11 » Fri, Jan 31, 2025, 5:25 PM UTC

philipwhiuk wrote: post #136

globular-toast wrote: post #103

Earlier quoted context omitted.

I did work in the industry briefly and can confirm it is actually full of people who would post a comment like this. Just in case anyone needed another reason to avoid it! Work on real problems. Try to make real people's lives better and happier. There are real problems in finance but my feeling was it's all very simple and solved decades ago, now it's just pointless complexity that isn't solving anyone's problems. I…

> Work on real problems. Try to make real people's lives better and happier. There are real problems in finance but my feeling was it's all very simple and solved decades ago, now it's just pointless complexity that isn't solving anyone's problems. I recommend John Kay's Other People's Money for a primer on what finance is actually good for and where it's gone wrong. If the last few years have taught me anything it's…

Not trying makes you a worse person.

Re: A better build system for OCaml

#182

Post by tempodox » Fri, Jan 31, 2025, 5:36 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".

I build my OCaml stuff with `make`. I use `dune` only for libraries, because it makes installing them super easy.

Re: A better build system for OCaml

#183

Post by wk_end » Fri, Jan 31, 2025, 5:49 PM UTC

emoII wrote: post #79

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

If anything the type system improves the run time speed, because the static analysis enables better code generation.

But I think what OP meant was more about the "functional programming" side of things than the "HM-typed" side of things. Naively, anyway, you might think that "the FP-style" of avoiding mutation and preferring recursion would require lots of garbage and high-latency garbage collection, copying, function call overhead...of course, that's not the whole story, but having Jane Street to point to as a crushing counter-example is nice.

Re: A better build system for OCaml

#184

Post by db48x » Fri, Jan 31, 2025, 5:53 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.

It’s a logical fallacy; it doesn’t rebut anything.

Re: A better build system for OCaml

#185

Post by [deleted] » Fri, Jan 31, 2025, 5:58 PM UTC

dumah wrote: post #160

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

Java https://github.com/openjdk/jdk/blob/master/Makefile Rust https://github.com/rust-lang/rust/blob/master/tests/run-make... Go https://github.com/golang/go/blob/master/src/runtime/Makefil... NodeJS https://github.com/nodejs/node/blob/main/Makefile OCaml https://github.com/ocaml/ocaml/blob/trunk/Makefile Python https://github.com/python/cpython/blob/main/Makefile.pre.in Haskell https://github.com/ghc/ghc/blob/master…

[deleted]

Re: A better build system for OCaml

#186

Post by cduzz » Fri, Jan 31, 2025, 6:02 PM UTC

deivid wrote: post #101

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 jobs at HFT deal with a lot of this fun--I was doing Linux at one for 6 years. A lot of jobs are extremely mundane though, compliance, regulations, legacy code bases, etc. Yes, all mitigations get disabled

Of course the mitigations get disabled.

What's the threat model where your HFT application's running hostile / untrusted code?

I'd like this stuff enabled on my desktop because I'm not sure what hideous javascript is being dumped into my browser by some advertising network.

But my trading platform? If the badguys are able to execute these attacks there, it's because they've got full access already.

Re: A better build system for OCaml

#187

Post by sestep » Fri, Jan 31, 2025, 6:19 PM UTC

ragnot wrote: post #166

yawaramin wrote: post #23

Dune's crash message: > I must not segfault. Uncertainty is the mind-killer. Exceptions are the little-death that brings total obliteration. I will fully express my cases. Execution will pass over me and through me. And when it has gone past, I will unwind the stack along its path. Where the cases are handled there will be nothing. Only I will remain.

I feel like I just got initiated into something

For context, this is adapted from the book Dune, after which the OCaml build tool was named. https://www.goodreads.com/quotes/2-i-must-not-fear-fear-is-t...

Re: A better build system for OCaml

#188

Post by edg-l » Fri, Jan 31, 2025, 7:04 PM UTC

i want to like ocaml but the tooling is not there, coming from Rust.

The lsp requires you to run "dune build" first, bad already.

If you add a new file, the lsp wont pick it up until you dune build it again.

The compiler errors arent there too.

But i loved writing OCaml, its just thats a bit more painful to learn than due to the tooling, since i didn't use many functional langs before.

Re: A better build system for OCaml

#189

Post by kqr » Fri, Jan 31, 2025, 7:38 PM UTC

patmorgan23 wrote: post #179

lotsofpulp wrote: post #157

Earlier quoted context omitted.

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.

Tighter spreads and higher liquidity is not economically productive? I can see arguments both ways.

Re: A better build system for OCaml

#190

Post by dgfitz » Fri, Jan 31, 2025, 8:17 PM UTC

PhilipRoman wrote: post #111

munificent wrote: post #25

Earlier quoted context omitted.

The only thing worse than a complex build system is a simple build system that can't build what you need to build. :(

After seeing enough bitbake recipes, I have to respectfully disagree. Some things are better off left unbuilt.

I wish I’d included this in my initial response:

I am painfully aware of bitbake. I’ve probably written 3-400 recipes.

Most of them are about 20-30 lines long, because I refused to hide the compilation mess inside a recipe. I fixed the problem _before_ getting to the bitbake part. Most of my recipes at this point need only a repo name, the recipes are identical after that.