Jane Street's sneaky retention tactic
economist.com
economist.com
But Jane Street is big enough now that 90%+ of their software hires aren't joining /because/ of ocaml, but in spite of it. The well of existing ocaml (or more generally, functional programming) enthusiasts who are qualified and willing to work for JS has been depleted for some time now. Rather than ocaml being a sort of shibboleth to hire only engineers who are passionate about programming languages, JS now hires the same sorts of engineers who would work at any other quant fund (ie, generally smart CS students who grinded C++, python, and leetcode questions in college), offers them slightly more money and a slightly nicer office than their competitors, and sends them all through a 2-week ocaml bootcamp.
but oh well, maybe ocaml is still worth it for the 10% of hires who actually are FP enthusiasts and would have otherwise gone into academia.
Hurts them how though? Is there no other merit to OCaml other than serving (or having served) as a tool to filter out new hires?
https://www.ft.com/content/24fea1d6-ba66-4b6b-814b-7bb72abfe...
Cringeworthy. Quant funds do in fact work on things like this. It's not that crazy.
Once you explain to the average person what a compiler is, they can draw a straight line from writing the compiler to the hedge fund reducing risk, gaining a competitive edge, whatever.
But this writer is choosing to hold up custom compilers as even more of an oddball move than counting cars, or shipping gold overseas. It's lazy writing from someone who is mistaking their lack of technical knowledge for common-sense insight into how strange software is. It is cringe.
Still... I seriously doubt this is much of a consideration for why they use OCaml.
I've swapped a decent number of tech stacks throughout my career. When I haven't used a stack for a few years it took months to get up to speed. Especially at a senior level where I should be capable of making design decisions, codebase level technical improvements, team workflow optimization, etc.
Obviously domain knowledge is important but I wouldn't trivialize technical side.
When hiring for a permanent position, I have the expectation that a programmer can learn a new language and environment. An OCaml programmer for a position that is python or C would be looked on very favorably. Far more attention-getting than “full-stack programmer”.
I would never want to work for a place like Goldman anyway, but knowing they had their own idiosyncratic tech environment would certainly be an additional negative.
One of the people I regard as the Godfather/OG strat is Emanuel Derman (https://emanuelderman.com/). Another transformative (in my time) person in the Strat complex was Marty Chavez (https://www.rmartinchavez.com/). Both amazing people on and off the trading floor.
They continued with their own db for decades out of inertia and also it worked fine. I think they've long since switched to TCP/IP and the public internet (for a time there was a Bloomberg network parallel to the public internet).
I'm sure everyone here is familiar with these two phenomena of the corporate world:
A) techie pushes tool not because it's useful or necessary but because he wants to learn the tool
B) something that started as happenstance ends up as a defining property of critical infrastructure.
I wasn't around when it was adopted, but it definitely felt like someone joined the company, evangelized Elixir, hired maybe half a dozen people who were really good at it, and then left.
Eventually, our Elixir experts evaporated, leaving maybe two people who truly understand it and can do difficult work in it. That's not sustainable.
Someone else in the comments here said that a good developer can be productive in any language, and that's true - but why hobble people? It's like saying a good surgeon can be productive with a butterknife and a pot of boiling water, or a good artist can be productive with a charred stick.
As a separate point, if a company wants the most generally applicable programming language, there is no reason to look further than C, yet few companies are like this.
Nor in the interest of the company at large, to be honest. Elixir doesn't really give us anything specific for our use case that other, more popular languages, don't also offer.
I think the analogy is also off a bit. I't be more apt to say a good surgeon should be expected to use electrosurgical units from different manufacturers, which is a completely fair expectation.
I wouldn't say Yaron Minsky was pushing OCaml because he wanted to 'learn' it. By that time he had already written the most popular PGP key exchange server...in OCaml: https://github.com/SKS-Keyserver/sks-keyserver/graphs/contri...
> Using Vcaml and Ecaml, they wired AI tools straight into Neovim, Emacs, and VS Code.. RL Feedback: The system learns from what works, tweaking itself based on real outcomes.. Jane Street records the [developer] journey — every tweak, every build, every “aha!” moment. Every few seconds, a snapshot locks in the state of play. If a build fails, they know where it went south; if it succeeds, they see what clicked. Then, LLMs step in, auto-generating detailed notes on what changed and why. It’s like having a scribe for every coder, building a dataset that’s not just big — it’s relevant. For niche languages or closed-off systems, this could be the future.
> For Jane Street’s technical rank-and-file, particularly the many hired straight out of university, non-compete agreements may be surplus to requirements. A scan of jobs listed by Millennium, a rival fund that has recently clashed with Jane Street in court, shows the strength of the latter’s position in the job market. Millennium wants engineers experienced in c++, Go, Java and Python, languages that are commonly used across finance and tech. OCaml developers, it seems, are Jane Street’s to keep.
If someone worked with OCaml at Jane Street I would just take this as a signal that they are smart enough to quickly learn Go, Python, whatever they need, and will probably be more successful after 6 months than a “Python developer” would be.
It's a tough situation being experienced in <peculiar language for Company A> when you need to ace technical interviews in <mainstream language for Company B>.
Once you have a few years of promotions, it gets even tougher when you need to compete with <mainstream language> senior+ software engineer candidates at the destination company. Maybe <flashy brand name> was enough to land the interview, but experience mismatches and limitations can remain apparent in the interview itself.
The retention factor is *not* that other companies wouldn't want to hire them, but rather that these employees are likely to dislike being forced to use something other than OCaml.
LLMs do make it easier, essentially by giving anyone the opportunity to to drop into a working codebase and take on practical tasks inside it.
I think 15 years ago I would have called out the imperative/functional divide as an exception, and that probably does still add challenge. But programming languages have progressed a lot, with imperative languages exposing you to a lot of functional concepts and functional languages having better ergonomics around state/IO.