What percentage of JS programmers actually work on this stuff I wonder?
The article said the team working on it has 5 engineers.
A better build system for OCaml
141–150 of 219 posts
Re: A better build system for OCaml
#142Earlier 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.
Re: A better build system for OCaml
#143Re: A better build system for OCaml
#144Earlier 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.
Re: A better build system for OCaml
#145Dune'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.
Re: A better build system for OCaml
#146I 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.
We used them at Bloomberg.
How is the design of the APIs? How stable are they?
Does Jane Street respond to bug reports/pull requests (if any) quickly?
Re: A better build system for OCaml
#147Earlier quoted context omitted.
I think that's true up to a point, but it misses the distinction between accidental and essential complexity. Essential complexity has to go somewhere, accidental complexity doesn't, and most complexity in software is accidental. And even when the complexity is essential, IMO it's better off not in the build system. I'll gladly accept more complex code for the sake of a simpler build (even though that theoretically m…
> accidental complexity doesn't, and most complexity in software is accidental. I strongly disagree. Most software is insufficiently complex to adequately represent reality.
That may be so; what I'm claiming is that most of the complexity in software as it currently exists is accidental.
Re: A better build system for OCaml
#148Re: A better build system for OCaml
#149Earlier quoted context omitted.
There's also pandoc written in Haskell. Facebook used it for it's spam-protection too, at some point (it might still do that, but I don't know).
Sadly I don't think it's used any more - it was migrated away from. I worked in integrity there and quite enjoyed whenever I had to make some changes to the Haskell rules :)