Let me know if I'm wrong, but it seems like Jane Street is going contrary to the HN common belief that a lot of things should be "buy" instead of "build" and yet they are quite successful
It's a case of an ellipse peg in an elliptic hole.
I doubt (for instance) that they have coded up their own HR system.
It is like paintings from famous painters in billionaire's homes. Now for me and may be for lot of people stuff from Bed Bath and Beyond is just fine on our walls. So for ultra-rich / successful/profitable company might see beauty in Ocaml but most of the world runs fine on run of the mill services in PHP/Java/.net etc.
most of the world doesn't run fine. If airplanes were built like your average software stack they'd drop out of the sky every other day.
Development practise at a place like JaneStreet is an example how things ought to be done. I really dislike the analogy of Ocaml as some sort of esoteric billionaire tool. It's just a sound language that everyone can understand, it's not even particularly academic despite its reputation. This is just what software engineering looks like if you actually treat it like... well engineering.
I missed to add C/C++ to my list. That would have covered real time systems you mention.
> Development practise at a place like JaneStreet is an example how things ought to be done.
As much I agree Jane street is doing cutting engineering for their domain, it seems unrealistic that rest of the world is unaware of good software engineering in generic usecases.
Depends on who is aware and whether they have the clout to actually implement it, the trenches are full of developers who know there are better ways and that those better ways would have a positive RoI but that it wouldn't show up possibly for 3-4 quarters minimum which makes it a hard sell to management if you can get them to even understand it without a tortured analogy - those programmers frequently don't have the authority to enforce the standards particularly when the other half in the trench with them are busy adding to the pile or actively fighting against it.
There have been times where I've wanted to shiv (figuratively) a developer who writes the worst most pointless convoluted code after he proclaimed code should be "self documenting".
Fortunately these days I'm at a level where at least for my teams I can enforce whatever standard we agree on and if we can't agree then the one I agree on - if we can't reach a consensus I operate on democratic principles, one man, one vote - I'm the man, I have the vote (though I try to avoid having to do that).
Another might say it was a weakness for snake oil.
To give you an example of how you would use some crypto-related library that implemented its API (?) in OOP:
let x = new Foo.bar in
x#absorb a;
x#squeeze b;
x#reset
This (this entire file) is a great example, too!
Ahrefs is another one I know of.
And hopefully (maybe?) my company soon.
Couple of things I took away from the experience:
- After an initial ramp-up, most of the developers liked or even loved the language. Downside was the limited tooling/libraries (2010-2015, seems better now).
- Quality of the resulting product was quite high: bug rate was fairly low, especially once experience with the language increased. Turns out sum types, gadts and the module system (functors) are very powerful to express invariants and design composable logic.
- OCaml was successfully picked up by team members without a formal computer science background, or even without a lot of programming experience. Not that it turns everybody into a great programmer, but it seemed to coerce new hires into delivering a working feature, without a huge risk of breaking a lot of other code.
- It is still possible to write crappy / unmaintainable code. But in OCaml it is often as easy (or even easier) to write good code.
- If something did turn out to be broken, it was painful. Debugger support (GDB) was initially non-existent. Under heavy load, we triggered a couple of bugs in libraries, which was quite painful to fix. On the other hand, we also triggered bugs in malloc and in the Linux kernel, which were as painful, so it might have had more to do with the high-load scenario, than with OCaml.
- For really low level stuff, or very high-performance cases, we did need to use the escape hatch to call C code. Interfacing Ocaml with C was not the most pleasant (was before ctypes library). Debugging bugs at that boundary was extremely unpleasant. One trigger for this was the fact that multicore OCaml never materialized, which also damaged the "political position" of OCaml within the company.
- Management (especially after the acquisition) was at best indifferent, and at worst hostile towards it. OCaml was perceived as being difficult to hire for (or outsource). Using more "standard" languages like Java, C++, Python was seen as the safer bet. They tried and often failed (C++ turns out to be damn complex, and maintaining a large Python codebase turned into whack-a-mole, but for bugs.).