Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

101–110 of 219 posts

Re: A better build system for OCaml

#101
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 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

Re: A better build system for OCaml

#102

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.

Love this! Thanks for posting.

Re: A better build system for OCaml

#103
post #88

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.

People outside the industry just use that as cope because they making way less money. "How do you live with yourself making high 6 fig / 7 figs a yr?" Quite easily in fact.

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 recommend John Kay's Other People's Money for a primer on what finance is actually good for and where it's gone wrong.

The real big problem in finance IMO is digital cash. Bitcoin started out trying to solve that problem, and there are still some people in the community interested in it, but it's mostly of interest to the finance guys now. Just another "instrument" in their "portfolios".

Re: A better build system for OCaml

#104

Earlier quoted context omitted.

Isn’t borrow checking only compile time?

Yes, but sometimes it forces you to write slightly slower code that can be proven safe.

You don't need s whole compiler for that... You can use `unsafe`. Sometimes you don't even need that either!

Re: A better build system for OCaml

#105
post #7

They did an episode of Signals and Threads (Jane Street's technical podcast) about their build systems back in 2020¥. Highly recommended, as are the other episodes, especially The Future of Programming with Richard Eisenberg° and What is an Operating System? with Anil Madhavapeddy§. ¥ https://signalsandthreads.com/build-systems/ ° https://signalsandthreads.com/future-of-programming/ § https://signalsandthreads.com/wh…

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

There's no deeper meaning, just done on a whim.

Re: A better build system for OCaml

#106

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

Would they also change the aliasing assumptions to something close to C/C++? Otherwise I imagine it would be relatively easy to make mistakes and get "surprises" at runtime thanks to the optimizer.

Re: A better build system for OCaml

#107
post #82
post #79

Earlier quoted context omitted.

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

dynamic typing incurs runtime overhead

That is obviously not what they meant since ocaml is not dynamically typed.

Re: A better build system for OCaml

#108
post #80

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

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.

With the "moving money at speed" part in the highly-optimised form of online betting.

Re: A better build system for OCaml

#109

Whenever I see posts from Janestreet blog I laugh inside thinking how working on the financial industry at Jane is probably more fun and rewarding than some 90% of the jobs in the so-called tech industry.

I had a friend who worked there and he claims they have a tonne of dogshit code and C++ as well.

He also claims they're full of elitists from top universities and are not receptive to ideas outside that bubble.

Re: A better build system for OCaml

#110
post #82
post #79

Earlier quoted context omitted.

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

dynamic typing incurs runtime overhead

HM is type inference for static typing, though, so wouldn’t have runtime overhead?
Post reply on HN