Having worked in the quant industry outside of JS, and being good friends with a couple JS employees, I'm of the opinion that in 2025 ocaml is hurting JS more than it helps them. Using an obscure programming language absolutely can help out your hiring effort at a small company; for example, I did an internship at quite possibly the only US-based company doing Common Lisp that hired undergrad interns. All my coworkers were extremely talented because (a) people who use Common Lisp are definitely PL enthusiasts rather than your typical FAANG-oriented CS college student and (b) without anywhere else to really go for an internship, they all ended up at this company and (c) they only needed a few interns so could afford to select only those who had prior common lisp experience.
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.
I'm of the opinion that functional languages (and even just languages with strong type systems) are only useful insofar as the people using them are "cooperative" with those features. If you write ocaml as if it were Python (and if your total FP experience is a 2-week ocaml bootcamp, what else can you do?) rather than actually designing your project in a way that eg takes advantage of the strong type system to prevent invalid program states, the advantages dwindle.
But you can't write OCaml as if it were Python because the language won't let you or make it hard for you. Add to that JS's internal processes that won't let you. So, by design of the language and JS's internal structures you will write code where some classes of bugs will be absent.
I don't disagree, but I still feel that JS has a relatively low attrition rate and people there are more than competent to know the limits of their tools — that it ends up being a net positive in the long run. I wish there was a way to quantify if/when the benefits outweigh the costs.
It’s hurting them if the benefits are smaller than the cost of having so many employees start from 0 with the programming language. It can take months or even years to get really good with a language, especially a whole new paradigm like functional programming.
Renaissance may have an unmatched PnL as a percentage, but jane street and Citadel, as market makers, just do way more volume than renaissance and their absolute PnLs are substantially greater than that of Renaissance.
Ehh idk I think there’s a sufficiently large group of people who like not just OCaml but also Rust, Haskell, Lisp, Elm, etc. It’s like a diaspora of programming language nerds.
"Hedge funds will go to great lengths in pursuit of profits, whether it is by counting cars in satellite photos of parking lots or shipping gold across the Atlantic. Building a compiler—a piece of software that turns human-written code into programs a computer can execute—for your homegrown language? That still raises eyebrows."
Cringeworthy. Quant funds do in fact work on things like this. It's not that crazy.
I don't think you know what "cringe" means... this really makes you cringe? And they didn't say it was crazy, they said it was interesting enough to raise eyebrows. Everyone knows there are amazing coders in hedge funds, but not many hedge funds have forked a language - it is worthy of discussion here.
I think you're reaching for an interpretation of what I said that's easier to challenge.
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.
It is fair competition. Using the same tools as one's competition yields similar gains. Using better tools increases the possibility of higher profits. Same as in manufacturing, chip making: better tools more profit. Potentially better profit. Nothing cringey about it.
But it's probably true that the developers who want to write OCaml have nowhere else to go really. And they're probably smarter on average than the average C++ developer.
Still... I seriously doubt this is much of a consideration for why they use OCaml.
Many years ago, I interviewed with Jane Street. They asked me C++ questions and if I am willing to learn OCaml. Sure, I can learn any language. The position was given to someone else who already knew OCaml. They use OCaml for everything, building software to distributing it etc. That's my interview experience with them. I think they chose that language because it can be as speedy as C++ with proper knowledge and optimizations. I do not know OCaml besides learning it when I worked with researchers/mathematicians who wrote OCaml and i had to understand the code.
I can see it working for an opposite reason. Someone who has been paid decently to write mathematically challenging software in an interesting and ergonomic language would probably want a premium to go somewhere they use a boring annoying language to solve lots of trivial problems. It is an extension of why game dev and to a lesser extent, embedded dev, pay less than full stack even if they are typically more challenging.
I've seen plenty of "write C/Java in any language" folk, working with them wasn't something I enjoyed and usually tried to distance from the mess. A few of them were domain experts but the codebase they produced was a nightmare to work on.
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.
The article doesn't understand programmers. People will stay because they are passionate about OCaml and there are not a lot of OCaml jobs.
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”.
If your only professional experience is OCaml and you want to look elsewhere for work then your opportunities shrink noticeably. Especially if you're looking for a position that requires experience. It's much more digestible for a company to hire someone out of college and invest in training on tooling. But many companies won't get past the resume if a senior developer has to take more time to on-board.
This is likely true for many companies. However, it is also a metric for what type of working environment it will be. I value being able to learn quickly and creativity over pre-training.
Goldman has done this for decades, pushing it even further by having developed their own language (Slang), graph db (SecDB), and IDE (SecView). Many engineers resist working it in, but for any strat it's mandatory.
Bloomberg did a similar thing decades ago, where they had their own database and their own take on TCP/IP. But this was done out of necessity since they started in the 80's and the database landscape looked very different than it does today.
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).
Yes, and our database, ComDb2, was open-sourced. It still powers the company today. And yes, we use TCP/IP :) And yes, we still have one of the largest private networks in the world.
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.
it means "strategy". I imagine each "strategy" looks at some data and decides what kinds of trades to make in response, or predicts the price of some securities and sends that to a downstream process which decides what trades to make based on those price predictions.
We learn OCaml in CS classes at écoles préparatoires (CPGE MP) in france. It’s an amazing language, practical to implement the CS math oriented theory we just studied. Doesn’t work that great as a retention tactic to stay forever at university though
It's not a tactic. The story was that at one point the tech person in charge wanted to use ocaml because he liked it. The project was a success and there was never any reason to change it.
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.
We're currently (very slowly) working to deprecate our Elixir codebase.
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.
From reading this, it sounds more like a management problem more than anything else. For example, retention goals should be such that all a companies experts (at anything, not just language) don't evaporate overnight and hiring goals should be such that experts are retrained and re-hired.
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 didn't say Yaron Minsky pushed OCaml because he wanted to learn it. I said it was because he liked it. Still, the distinction isn't important to the point I was trying to make.
> 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.
The people who work at Jane Street are not OCaml developers, even though some of them work on the language. They’re software engineers which are most probably smarter than your average $LANG developer.
this let's them freeze architecture into language constraints. they’re writing rules of the system into the type system itself. you dont need to document invariants, cuz already you have encoded them. what that does long-term is kill tribal knowledge. new hires dont need to ask what does this function assume , they cant even write it wrong if the types dont let them
The article isn’t really very persuasive about this though. Having worked with OCaml at Jane Street is not, I think most of us would agree, going to be, going to be a serious barrier to getting hired to work with another language somewhere else.
> 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.
I've experienced this while leaving a different company that used a rare language.
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.
> Having worked with OCaml at Jane Street is not, I think most of us would agree, going to be, going to be a serious barrier to getting hired to work with another language somewhere else.
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.
Sure you would, but would Millennium or other high-caliber firms? It seems they want engineers with C++ experience and that's not exactly 'easy' to pick up 'quickly'.
This tactic won't work so well anymore in the age of LLMs. With the exception of horror movies like C and C++, is now very easy to learn and work with a new language by learning it on the go while working with it using an LLM. One can and should ask an LLM a dozen questions to explain what is happening. Expertise absolutely still matters, but less than it did before.
It's always been pretty easy to learn any language "on the go" if dropped directly into a functioning codebase, with practical tasks to undertake in it. Even the "horror movie" languages you called out which obviously many many people have learned.
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.
No, rather, Jane Street is not a candidate for me. Anyone who is actually smart can trade on their own and make a good living, and doesn't need to work for a company that does it. By corollary, anyone who works for someone else's trading firm is not actually so smart.
I think people are misunderstanding you to think using an LLM to generate code, whereas you’re discussing using an LLM to learn a language. LLMs can be teachers with infinite patience.
Having worked in the quant industry outside of JS, and being good friends with a couple JS employees, I'm of the opinion that in 2025 ocaml is hurting JS more than it helps them. Using an obscure programming language absolutely can help out your hiring effort at a small company; for example, I did an internship at quite possibly the only US-based company doing Common Lisp that hired undergrad interns. All my coworkers were extremely talented because (a) people who use Common Lisp are definitely PL enthusiasts rather than your typical FAANG-oriented CS college student and (b) without anywhere else to really go for an internship, they all ended up at this company and (c) they only needed a few interns so could afford to select only those who had prior common lisp experience.
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.
> In 2025 ocaml is hurting JS more than it helps them
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?
I'm of the opinion that functional languages (and even just languages with strong type systems) are only useful insofar as the people using them are "cooperative" with those features. If you write ocaml as if it were Python (and if your total FP experience is a 2-week ocaml bootcamp, what else can you do?) rather than actually designing your project in a way that eg takes advantage of the strong type system to prevent invalid program states, the advantages dwindle.
But you can't write OCaml as if it were Python because the language won't let you or make it hard for you. Add to that JS's internal processes that won't let you. So, by design of the language and JS's internal structures you will write code where some classes of bugs will be absent.
I don't disagree, but I still feel that JS has a relatively low attrition rate and people there are more than competent to know the limits of their tools — that it ends up being a net positive in the long run. I wish there was a way to quantify if/when the benefits outweigh the costs.
Sure, and if you write Python as if it were Java and your total Python experience is a 2-week bootcamp, the advantages dwindle.
Have you read "Dreaming in Code"? This is a key theme in one section and I recall it was quoting Philip Eby https://dirtsimple.org/2004/12/python-is-not-java.html
It’s hurting them if the benefits are smaller than the cost of having so many employees start from 0 with the programming language. It can take months or even years to get really good with a language, especially a whole new paradigm like functional programming.
[flagged]
Jane Street is arguably the most successful trading firm in history. I want to hurt as badly as they're hurting!
How are they more successful than Renaissance Technologies?
Renaissance may have an unmatched PnL as a percentage, but jane street and Citadel, as market makers, just do way more volume than renaissance and their absolute PnLs are substantially greater than that of Renaissance.
'Jane Street trading revenues nearly doubled in 2024 to more than $20bn'
https://www.ft.com/content/24fea1d6-ba66-4b6b-814b-7bb72abfe...
Ehh idk I think there’s a sufficiently large group of people who like not just OCaml but also Rust, Haskell, Lisp, Elm, etc. It’s like a diaspora of programming language nerds.
at least for the new grad pipeline, I'm gonna stick with 10% as my number for all PL enthusiasts combined.
"Hedge funds will go to great lengths in pursuit of profits, whether it is by counting cars in satellite photos of parking lots or shipping gold across the Atlantic. Building a compiler—a piece of software that turns human-written code into programs a computer can execute—for your homegrown language? That still raises eyebrows."
Cringeworthy. Quant funds do in fact work on things like this. It's not that crazy.
I don't think you know what "cringe" means... this really makes you cringe? And they didn't say it was crazy, they said it was interesting enough to raise eyebrows. Everyone knows there are amazing coders in hedge funds, but not many hedge funds have forked a language - it is worthy of discussion here.
I think you're reaching for an interpretation of what I said that's easier to challenge.
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.
It is fair competition. Using the same tools as one's competition yields similar gains. Using better tools increases the possibility of higher profits. Same as in manufacturing, chip making: better tools more profit. Potentially better profit. Nothing cringey about it.
You're misreading the comment.
Symmetry investments had a similar relationship with the D language.
Author doesn't seem to understand that skilled programmers can be productive in almost any language. Experience in the domain is more important.
But it's probably true that the developers who want to write OCaml have nowhere else to go really. And they're probably smarter on average than the average C++ developer.
Still... I seriously doubt this is much of a consideration for why they use OCaml.
Many years ago, I interviewed with Jane Street. They asked me C++ questions and if I am willing to learn OCaml. Sure, I can learn any language. The position was given to someone else who already knew OCaml. They use OCaml for everything, building software to distributing it etc. That's my interview experience with them. I think they chose that language because it can be as speedy as C++ with proper knowledge and optimizations. I do not know OCaml besides learning it when I worked with researchers/mathematicians who wrote OCaml and i had to understand the code.
I can see it working for an opposite reason. Someone who has been paid decently to write mathematically challenging software in an interesting and ergonomic language would probably want a premium to go somewhere they use a boring annoying language to solve lots of trivial problems. It is an extension of why game dev and to a lesser extent, embedded dev, pay less than full stack even if they are typically more challenging.
I've seen plenty of "write C/Java in any language" folk, working with them wasn't something I enjoyed and usually tried to distance from the mess. A few of them were domain experts but the codebase they produced was a nightmare to work on.
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.
The article doesn't understand programmers. People will stay because they are passionate about OCaml and there are not a lot of OCaml jobs.
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”.
If your only professional experience is OCaml and you want to look elsewhere for work then your opportunities shrink noticeably. Especially if you're looking for a position that requires experience. It's much more digestible for a company to hire someone out of college and invest in training on tooling. But many companies won't get past the resume if a senior developer has to take more time to on-board.
This is likely true for many companies. However, it is also a metric for what type of working environment it will be. I value being able to learn quickly and creativity over pre-training.
Goldman has done this for decades, pushing it even further by having developed their own language (Slang), graph db (SecDB), and IDE (SecView). Many engineers resist working it in, but for any strat it's mandatory.
Bloomberg did a similar thing decades ago, where they had their own database and their own take on TCP/IP. But this was done out of necessity since they started in the 80's and the database landscape looked very different than it does today.
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).
Yes, and our database, ComDb2, was open-sourced. It still powers the company today. And yes, we use TCP/IP :) And yes, we still have one of the largest private networks in the world.
https://github.com/bloomberg/comdb2
What is a "strat"?
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.
It's a tech/quant role.
A job title, then...? I took it for a description of the company; web search turns up only references to guitars and some hotel in Las Vegas.
Quantitate Strategist. Most places call this role a Quant.
it means "strategy". I imagine each "strategy" looks at some data and decides what kinds of trades to make in response, or predicts the price of some securities and sends that to a downstream process which decides what trades to make based on those price predictions.
and low latency messaging: tervella. (2014-2015, I had to deal with it.)
We learn OCaml in CS classes at écoles préparatoires (CPGE MP) in france. It’s an amazing language, practical to implement the CS math oriented theory we just studied. Doesn’t work that great as a retention tactic to stay forever at university though
Lots of universities teach Haskell as part of a CS degree, and that has not too much use in the world outside academia...
It does have some places! I used it at IOHK, they use it at Mercury, a little at Meta, Galois, etc...
I'm still in love with Caml from my time in prépa, one of the reasons I'm sometimes eyeing JS for a move.
https://archive.ph/u10ol
It's not a tactic. The story was that at one point the tech person in charge wanted to use ocaml because he liked it. The project was a success and there was never any reason to change it.
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.
We're currently (very slowly) working to deprecate our Elixir codebase.
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.
From reading this, it sounds more like a management problem more than anything else. For example, retention goals should be such that all a companies experts (at anything, not just language) don't evaporate overnight and hiring goals should be such that experts are retrained and re-hired.
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.
Interesting. So the people you already have can't just learn Elixir to the required standard or rather doing so is not in their self-interest.
Interesting. So the people you already have can't just learn Elixir to the required standard.
> techie pushes tool not because it's useful or necessary but because he wants to learn the tool
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...
I didn't say Yaron Minsky pushed OCaml because he wanted to learn it. I said it was because he liked it. Still, the distinction isn't important to the point I was trying to make.
Jane Street's reported use of LLMs + OCaml, https://archive.is/HSVJN
> 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.
The people who work at Jane Street are not OCaml developers, even though some of them work on the language. They’re software engineers which are most probably smarter than your average $LANG developer.
My sneaky retention tactic is Elm... I'm only retaining myself though :)
If they've managed to escape Python for machine learning tasks then it's worth it imo.
this let's them freeze architecture into language constraints. they’re writing rules of the system into the type system itself. you dont need to document invariants, cuz already you have encoded them. what that does long-term is kill tribal knowledge. new hires dont need to ask what does this function assume , they cant even write it wrong if the types dont let them
This is kind of a weak and fluffy article coming from the Economist. As a long term subscriber I’m disappointed.
If you don't like weak and fluffy, perhaps skip this week: https://www.economist.com/science-and-technology/2025/06/27/...
This is similar to Epic Systems (the healthcare SaaS company) and Mumps.
Whats the WLB balance like at JS? I would have loved to be making $1mn straight out of college!
None whatsoever. Unless you have no life, it makes no sense to work for them
more like work-work balance
It’s not obscure.
to the users of this site probably not, but it is also only used by 0.8% of developers extensively [1].
[1] https://survey.stackoverflow.co/2024/technology
Objective C is at 2.1%, defo not an obscure language.
[dead]
tldr: OCaml
The article isn’t really very persuasive about this though. Having worked with OCaml at Jane Street is not, I think most of us would agree, going to be, going to be a serious barrier to getting hired to work with another language somewhere else.
> 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.
I've experienced this while leaving a different company that used a rare language.
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.
> Having worked with OCaml at Jane Street is not, I think most of us would agree, going to be, going to be a serious barrier to getting hired to work with another language somewhere else.
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.
Sure you would, but would Millennium or other high-caliber firms? It seems they want engineers with C++ experience and that's not exactly 'easy' to pick up 'quickly'.
That programming language your doctor doesn't want you to know about.
tldr: OCaml and no non-competes
[flagged]
This tactic won't work so well anymore in the age of LLMs. With the exception of horror movies like C and C++, is now very easy to learn and work with a new language by learning it on the go while working with it using an LLM. One can and should ask an LLM a dozen questions to explain what is happening. Expertise absolutely still matters, but less than it did before.
It's always been pretty easy to learn any language "on the go" if dropped directly into a functioning codebase, with practical tasks to undertake in it. Even the "horror movie" languages you called out which obviously many many people have learned.
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.
Somehow I don't think you're going to be a candidate for Jane Street.
No, rather, Jane Street is not a candidate for me. Anyone who is actually smart can trade on their own and make a good living, and doesn't need to work for a company that does it. By corollary, anyone who works for someone else's trading firm is not actually so smart.
Or it just they didn't think they can make it on their own, so they didn't develop the necessary expertise.
LLMs are not so good at less popular languages. They know the basics but they also quickly get confused.
I think people are misunderstanding you to think using an LLM to generate code, whereas you’re discussing using an LLM to learn a language. LLMs can be teachers with infinite patience.