Why does Jane street use purely Ocaml

[-]

wvenable@reddit

I know someone who used to work at Jane Street, where OCaml is the language of choice. A lot of the discussion here seems to overlook the real reason they use it. Yes, OCaml has its strengths, but just as importantly, it’s a niche language—and that’s by design.

By using a tool that most developers well never even encounter in their career, they’re filtering for a particular type of candidate: someone who seeks out obscure, academically-influenced technologies and is up for that challenge. It’s not just about technical capability; it’s about mindset and culture fit.

Personally, I don’t think I align with that philosophy -- I'm probably the opposite of a Jane Street programmer -- but I can see how it works for them. They're not necessarily picking the "best" tool for the job in a conventional sense. They're choosing a tool that selects for the kind of people they want to hire.

[-]

FormerKarmaKing@reddit

A loved one was a recruiter at Jane St. This is the answer. Jane St is intentionally a fun place for sincere math nerds to work. And they recruit against the richest companies on earth for talent from just a few schools, at least when it comes to quants.

So on top of the value of a purely FP language, yes it’s absolutely a filter. See the Python Paradox essay by Paul Graham for an older example of this.

[-]

amtcannon@reddit

Oh the irony remembering an article where python is the niche cutting edge language.

[-]

FormerKarmaKing@reddit

Tbh I have no idea why PG loved Python so much, except for maybe some libraries. And having had to deal with e-commerce code written in Python - which was what his company did - it would not be my anywhere near my first pick.

[-]

amtcannon@reddit

I remember python being incredibly exciting, and the only real alternative for a lightweight web language with no need for mega expensive servers and licences was PHP.

Python and PHP both revolutionised the way the web worked. Just making any sort of web application back then was terrible and expennnnnsssssive. Not to bash PHP - it genuinely changed the world - but python attracted more super smart new developers than PHP did.

Ditching Java or dotnet (or C) for LAMP was a revolutionary act at the time, you have to remember the context. It was so cheap to run, so easy to write, it was an incredible step up in allowing entrepreneurs to build real applications.

We were all blown away by python, just import a library and it’ll let you do stuff, there are libraries for everything! It was incredible. It had its own memory management, it was easy to write, it had an easy to learn syntax. It even hid all the bugs so it seemed even easier to write than it was!

[-]

ThePillsburyPlougher@reddit

It definitely works because they've been printing money for the last several years

[-]

thekwoka@reddit

Yeah. Introducing aspects of your company that cause applicants to self select works really well in a market FLUSH to terrible engineers who did a bootcamp and lie their way through everything.

[-]

irespectwomenlol@reddit

Don't know much about Ocaml.

This might be less about the technology, and more about other reasons.

1) Hiring. There might not be a lot of Ocaml people compared to Java people, but everybody who wants to do Ocaml has heard of you and would likely consider joining you. Additionally, the average Ocaml dev is probably less likely to be bad/inexperienced as nobody picks up Ocaml from a bootcamp for a first bit of experience.

2) Having some kind of gimmick is a marketing tool. Many companies out there can do some Java. But Ocaml sounds exotic and mysterious and special. Maybe some potential customers view it as a secret competitive edge?

3) Employee retention. If you've done nothing but Ocaml for the last 10 years, you might be hesitant about moving on to new pastures.

4) Influence. If Jane street needs there to be some new Ocaml language feature, they probably have the heft to steer the language in the direction they need. Whereas if they need some Java feature, they're not going to be able to influence that very much.

[-]

aabil11@reddit

I've had issue #3 as a Scala dev for 5 years

[-]

bamfg@reddit

great answer. point 4 bears emphasising, they don't just steer the language in a direction, they actively work on the ocaml compiler - i believe they maintain their own fork with their own features

[-]

Getabock_@reddit

I thought I had a stroke when reading your comment at first “point 4 bears? point 4 bears?! 🐻 “ until I realized you meant “it’s worth it to emphasize point 4” hahaha

[-]

lab-gone-wrong@reddit

Imagine being held at gunpoint (bear with me) by a literate animal, and the only hope of rescue is (BEAR WITH ME) posting a coded message on Reddit.

[-]

AnotherPersonNumber0@reddit

That's BARE with me.

[-]

Equivalent-Wall4980@reddit

i believe they maintain their own fork with their own features

Yes, although in all cases the goal is to eventually upstream those features.

[-]

thekwoka@reddit

the average Ocaml dev is probably less likely to be bad/inexperienced as nobody picks up Ocaml from a bootcamp for a first bit of experience.

This is a huge one.

A ton of the stuff people attack "entry" languages like Python and JS for are just the results of it being a language people get into with minimal experience and passion. So they make tons of crazy stuff.

Now, Python is objectively bad for many reasons beyond that, but it is a major contributor.

[-]

Jaded_Athlete885@reddit

Jane Street are the core maintainers for the OCaml standard library now I believe.

[-]

theweirdlittlefrog@reddit

thanks chatgpt

[-]

shagieIsMe@reddit

ChatGPT wouldn't be making some of the mistakes like Ocaml rather than OCaml (this even has Ocaml show up as a typo in the text box). Jane street rather than Jane Street is another (and it would likely use the full name). It would also be using markdown bulleted lists rather than 1). It would Laos likely be using a more formal style guide so that ten would be written rather than 10 and Whereas would be followed by a comma.

[-]

selucram@reddit

thanks claude

[-]

irespectwomenlol@reddit

I'll consider it a compliment that my posts are so thorough that they can be mistaken for a cyborg.

[-]

tikhonjelvis@reddit

If you've done nothing but Ocaml for the last 10 years, you might be hesitant about moving on to new pastures.

I mean, at some point, you're going to be experienced enough to not worry about picking up a new language. I'm surprised that this is not a baseline expectation for experienced developers.

Jane Street does have remarkable retention, but it's mostly because they have a culture that really works for some people and they out-pay basically any software engineering role that would be comparable.

[-]

Ok_Slide4905@reddit

“We have 5 engineers who know OCaml and 0 engineers that know JavaScript.”

“So, OCaml it is then?”

“Yep.”

[-]

_hypnoCode@reddit

"maybe we can hire the other 5 engineers in the world who use OCAML too"

"what about after that?"

"🤷‍♂️"

[-]

PragmaticBoredom@reddit

After that, the new hires have no choice but to get on board with the language everything is written in.

Critical mass.

[-]

Chemical-Plankton420@reddit

I worked at a company that really liked knockout.js. We eventually had to switch to React and rewrite the front end and do all sorts of magic to make it work because we couldnt find any knockout devs

[-]

PragmaticBoredom@reddit

Oh yeah, that’s the other half of the requirement: You have to pay a lot of money.

Jane Street has high comp. People will gladly learn a new language for that sort of TC.

They will not learn an unpopular framework for average pay.

[-]

mdibmpmqnt@reddit

Plenty of people would think ocaml on your resume is interesting, not so much knockout these days

[-]

Chemical-Plankton420@reddit

My old manager does Ruby on Rails and he’s always in demand. OCaml has been around forever.

[-]

MCFRESH01@reddit

Ruby is nowhere near dead despite what people think.

Source: Rails dev

[-]

Ok_Slide4905@reddit

EmberJS has left the chat

[-]

MCFRESH01@reddit

I actually like a lot of what ember was trying to do

[-]

noir_lord@reddit

In it’s day knockout was amazing for a primarily backend dev, it was the first time I though using JS didn’t make me want to defenestrate Brendan Eich.

Svelte feels much the same but is more modern.

[-]

_hypnoCode@reddit

My company uses a semi-niche language as our main backend stack and we don't hire people with the expectation that they know it.

However, it's not so niche that we can't find experts in the language. Learning a new language shouldn't be difficult for any good developer, but sometimes that expert level knowledge of nuances and edge cases is invaluable.

[-]

AustinYQM@reddit

When I was fresh out of college I had a job tell me: "Honestly I would love to hire you but I think it would be a terrible idea fro your growth. We use in-house languages and tools and much of what you learn here you just doesn't transfer anywhere else. Come back in 20 years when you are ready to settle in for the long haul and we can talk."

[-]

PragmaticBoredom@reddit

I’ve been there too. Offering boatloads of TC fixes that problem quickly.

If you can’t offer high TC, stick to a popular language.

[-]

guareber@reddit

I know someone who learned OCaml to try and get into this kind of work and... it's not just 5 engineers. The jobs are very contested.

[-]

tikhonjelvis@reddit

Hire the sort of people who can learn a new language, and then expect them to learn that new language?

I'm surprised that this isn't a baseline expectation for experienced engineers.

That's also why the parent comment is wrong: if using JavaScript led to a better engineering experience than compiling OCaml to JavaScript they would have, because learning JavaScript is not a real hurdle. They didn't because they really like the expressiveness and type-safety that OCaml provides, as well as having smooth integration across all their other internal tools and libraries.

For areas where this isn't the case—like Python for machine learning—they are totally willing to invest in Python code and tooling, to the point that they have like 3M lines of Python these days.

[-]

_hypnoCode@reddit

I commented below about this. My company does that, learning a new language should be trivial for most good developers. We use a language that isn't that popular anymore, but still has plenty of experts. We don't hire with the expectation that developers know the language though.

But discounting expert level knowledge isn't good either. Not having plenty of people who know and understand the nuances and edge cases can be downright dangerous for production code.

[-]

aj8j83fo83jo8ja3o8ja@reddit

lmao

[-]

Even_Research_3441@reddit

OCaml is a really nice language, they have devs experienced in it.

"Right tool for the job" is tautological. If we all agreed on what that was then fine. But it can be contextual. Very often it makes no difference what language you use so using what you know all up and down the stack is nice.

But OCaml (and F#) are really nice, they may be on to something =)

[-]

datanaut@reddit

Not sure how it started but now they also have hardcaml: https://github.com/janestreet/hardcaml And probably a lot of other tools that have made Ocaml quite entrenched

[-]

PragmaticBoredom@reddit

When your early engineering team really likes a specific language they hire more people who like that language.

Eventually everything is written in that language and new hires have to learn it.

In Jane Street’s case, it also gives them something unique to advertise and intrigue people.

[-]

BringBackManaPots@reddit

Ours was/is scheme

[-]

Shnorkylutyun@reddit

So... You're a schemer?

[-]

BringBackManaPots@reddit

Hah yeah. I am now! It's awful to hire for though. I pretty much just give people a textbook when they start.

[-]

BomberRURP@reddit

Is this because of the Paul graham article? https://www.paulgraham.com/avg.html

Anyway, neat. What do you guys build?

[-]

kagevf@reddit

Which Scheme? There're so many...

[-]

positivelymonkey@reddit

This goes against my knowledge of, use the best tool for the job.

Maybe you're knowledge is wrong? Maybe the best knife in the kitchen draw is simply the one you use the most.

[-]

Noddybear@reddit

OCaml is based off ML - which is a formally verifiable and proveable language. This eliminates entire classes of bugs and issues in what is extremely critical software. It is not purely a stylistic choice.

[-]

Logical-Ad-57@reddit

"Why would you want a mathematically proveable language on the frontend anyways."

In Finance there's a huge amount of uncertainty going into if something is working or not. A system that's right 50-60% of the time consistently for 30 years is a career worth 100mil in salary for the individual who built that strategy. Problem is, you don't know if you're seeing variance, and the market adaptively fights you to try and squeeze that 50-60% into 40-50% which lets them be worth 100mil and gets you fired.

In such an environment people frequently will accept lower performance, more complicated, more painful solutions if they can confidently eliminate some of the uncertainty that differentiates between a strategy performing 51% vs 49%. If you 100% know your front end is correctly displaying your data because you have a bunch of checks passing, that means you don't have to worry about that as you try to figure out if your math is wrong, or your implementation is wrong, or your economic assumptions are wrong, or if someone just got your goat some way.

Not arguing for or against OCaml, but as usual, smart people are doing strange things for a reason. You could argue its not a good reason and you don't want to play this game, but it is a reason.

[-]

godisb2eenus@reddit

Your point about smart people doing things for a reason reminded me of Nietzsche's quote:

"And those who were seen dancing were thought to be insane by those who could not hear the music"

Those arguing about the "right tool for the job" likely have no clue about the shape of the problems Jane Street solves or what business and technical constraints they optimise for, and yet they infer their solutions are not adequate...

[-]

gowithflow192@reddit

Literally no reason than navel gazing, or other companies would do the same too and invent their own language and force every employee to learn it (which is what Jane St do).

[-]

corgiyogi@reddit

WhatsApp scaled to 50B users with 50 engineers with erlang. Makes you wonder who really is using the "best tool"

[-]

sm0ol@reddit

Brother how many people do you think exist on earth?

[-]

thekwoka@reddit

Well, I guess...multiple accounts per person and business accounts...

nah still doesn't add up.

[-]

ecethrowaway01@reddit

50 billion?

[-]

zhemao@reddit

Erlang probably IS the best tool for that specific job though.

[-]

Altruistic_Raise6322@reddit

You mean 2 billion users?

[-]

throwawayacc201711@reddit

Everyone suffers from premature optimization and the industry at large. The idea that you will be “pulled” forward is for such a small number of companies but somehow everyone thinks it applies to them. This happens when you hit some scaling factor and then you decide to building X tooling to solve for it. Most companies aren’t gonna hit that size. But everyone gets bought into it and wants to use what “big tech” or whatever is using. So they decide we’re gonna start using X and I’m gonna start learning X. However you don’t need X. You won’t see the benefits of X until you get to Y scale. However X slows you down until you get to Y scale. But then people get hired at companies that are much lower than Y scale, but they bought the X koolaid so now they advocate for adopting X.

Use the simplest tool for the job. Don’t over complicate your life. Just follow good design principals.

[-]

Farva85@reddit

Gawd darn how many bot accounts exist on that platform.

[-]

geeeffwhy@reddit

because the marginal value from switching to something else is lower than the cost of switching to something else.

and as a corollary, consistency is a value unto itself.

[-]

takuonline@reddit (OP)

If that is true, it should be more common. I can't thing of any other big company that does this, can you?

[-]

New_Enthusiasm9053@reddit

All of them? Apple/Google/Microsoft all have major not invented here syndrome. Apple has made Objective C/Swift, MS has made C#/F#/Visual Basic/Powershell, Google is making its own OS Fuchsia as well as Carbon, also made Go.

Shit if you're big you need projects like that to keep the engineers happy, at least it's vaguely helpful.

[-]

codemuncher@reddit

So I used to work at Google.

Before people go on about “not invented here” syndrome, you have to remember that many of the ultra custom things they wrote didn’t have any reasonable equivalents when they wrote them.

A lot of their tech was pioneered circa 2005 or so, when no one did “web scale”. The premiere “super computing clustering” was bewolf and maxed out at just a few hundred computers. Hence borg. Load balancers? Proprietary hardware that wasn’t software configurable. Hence gfe. Rpc interop? Everyone was drooling over soap-xml which was always terrible and inefficient. Hence protobuf.

The google today is the logical extension of their own ecosystem. And it drives incredible strength. They will never be affected by an nginx, Apache tomcat, even openssl 0-day. Why? Because they don’t use it!

Obviously this advice doesn’t scale down, but if you have the money and talent it works. And can give you a massive advantage. When was the late time Google was hacked?

Regarding Apple and Microsoft, your argument makes no sense. They’re operating systems and developer tool vendors. This is what they do - they make the kinds of things you list.

You are right about Google and go. Oh my god what an abomination of a programming language. Hate it.

[-]

New_Enthusiasm9053@reddit

Ok but they'll be hit by their own vulnerabilities on their own stuff(and it'll likely go unnoticed for longer) so it's not realllly an argument.

But yes, it's not inherently a problem, making your own shit is cool and a vaguely good engineer is still gonna make a better product even if it's arguably not worth the effort. Kubernetes(based on borg apparently) for example is indeed a very nice tool.

My point is Carbon isn't really justifiable nor is Fuchsia but if it keeps top engineers happy so they'll work on ad stuff when needed then it's worth it. People don't join Google to work on ad Services, they want to work on cool stuff.

The engineers allowed to work on their own OS are the equivalent of Ronaldo/Messi to football, millions of kids/engineers want to be them, only a handful will.

Arguably those projects are more to keep up company morale than for actual genuine business reasons.

[-]

syklemil@reddit

Carbon and their forays into Rust seem at least in part due to the C++ committee rejecting some stuff they really wanted. Basically with the two factions of C++, the legacy C++ faction won, and Google and the people who wanted an ABI break and so on lost. Carbon is likely more of a "how can we manage our C++ codebase with government requirements" thing than anything else.

Today's Microsoft—who's rewriting their Typescript compiler in a language made by one of their competitors—possibly wouldn't have made as many .NET languages. But they all seem to be working their way away from C++, and none of them seem to have NIH worries about Rust.

[-]

New_Enthusiasm9053@reddit

Yes because Rust is actually just good. It's the only memory safe, no GC language out there. It was clearly built by people who know what C++s problems are.

And TBF to the C++ committee, the language spec is so complex you can't even parse it fast enough for a linter anymore. The Clang people said they had to make a separate, not fully spec compliant parser that was sometimes just wrong because otherwise it was impossible to make it fast enough. The language is genuinely just an abomination. The ideas behind it aren't necessarily bad but its starting to sink under its own weight.

Carbon is an attempt to fix that but idk how that's going.

[-]

codemuncher@reddit

Rust is great, but it has its own trade offs and no language is perfect.

Case in point, rust async has terrible ergonomics. I did a rust async project and discovered a compiler bug. That’s how difficult async is.

Also don’t get me started how your error type has to be the sum of every error type and library in your entire project. Ugh.

So let’s not attribute perfection to rust.

Also the user interface toolkits of iOS and Mac have their roots in… the early 90s. Next step and cocoa via objective c was absolutely amazing and way better than any of the C/C++ crap. Notably react didn’t exist.

So it ain’t as simple as “use rust, rust always good”

[-]

thekwoka@reddit

Also don’t get me started how your error type has to be the sum of every error type and library in your entire project.

Why would it need to be that?

That doesn't make much sense at all.

That's only if you just always pass any errors up and never handle them yourself.

So let’s not attribute perfection to rust.

Yeah, I really like Rust and think it's definitely the best for anything truly critical, but it's not perfect. It's pretty dang close though.

[-]

New_Enthusiasm9053@reddit

In my defence I said just good, I never said perfection, as procedural cross platform languages spurred an evolution in design and GCed languages spurred an evolution in design themselves thereafter, Rust will do the same. It will almost certainly not be the final language to rule them all. But for now it's in my opinion pretty good but objectively at least unique.

[-]

codemuncher@reddit

Hey some people want HM type inference or death, so there’s still plenty of PL research rust doesn’t touch…, yet?

[-]

thekwoka@reddit

It's the only memory safe

eh, I think you'd have to get to a definition of "memory safe" with this that isn't entirely fair.

Since, we know that Rust (even safe rust CAN have memory unsafety issues) and that there are other languages that do a lot of the memory safety things that Rust does.

So Rust isn't entirely memory safe, and others are close, so the window in which "Memory Safe" includes Rust and NOTHING else is quite small.

[-]

syklemil@reddit

Yeah, I was exposed to the "Curiously recurring C++ bugs at Facebook" from Cppcon 2017 recently and I'm kinda curious what Louis Brandy thinks of Rust—can't recall if all the problems he lists are gone in Rust, but I'd be willing to guess they are.

The C++ committee also isn't evil or incompetent or anything; it's just sometimes in politics you have groups who have mutually exclusive goals. The people who have a huge interest in continuity are representing their interests the same as people who have an interest in a continuity break, but ultimately one of them has to win and the other lose—they either get an ABI break or they don't, etc. It's a tough position to be in and I don't envy them.

[-]

codemuncher@reddit

A side note to other people, “why not rust?” - things the op and grand parents decries as nih were invented before rust was a thing and inventing their own language seemed reasonable at the time.

Remember extending something like C++ at a language level could never be part of a product strategy: iso standardization committees man. They’re more bureaucratic than anything you’ve ever seen, short of the UN perhaps.

[-]

syklemil@reddit

Yeah, MS has their own compiler so their NIH would likely just extend to other compilers, and there's a big enough legal backstory with C# vs Java for those interested.

There's a lot of history around programming languages, and power & control is a part of that history, just as it is with other history. And some of it, like evolving Visual Basic to VB.NET was likely just a sensible thing to do at the time, even if most of us have likely all but forgotten it was a thing by now, just like we have with Tcl/Tk and a lot of other languages that had a good go, but were ultimately left behind.

And yeah, Rust needed a sufficiently advanced compiler and hardware to get going. It's a fine language in many respects, but I can't see it working on, say, 90s computers.

[-]

codemuncher@reddit

Have you ever done ui programming using the “standard” languages available when Apple was putting forward what evolved into iOS and swift?

I’m talking C and C++ coding circa 1995-2005.

It was a nightmare and a lot of the problem was the programming languages.

So objective c wasn’t so insane. The resulting ui libraries have survived the test of time, and swift is a surprisingly small upgrade over objective c.

[-]

New_Enthusiasm9053@reddit

I never said objective C was insane, just merely that perhaps the same effort dedicated to libraries could have(but perhaps not) yielded similar gains.

I don't think a home thinks make a new language is quite as easy as make a new ergonomic language, it's possible it was the right choice but it's invariably the riskier choice.

[-]

codemuncher@reddit

As a fun history note, the earliest objective c was basically macros on top of C and some libraries.

I do think we need to recognize that C as a programming language is not good for large scale programming. The same goes for a lot of different programming languages as well.

Expressiveness is important, along with type and compiler support. If you keep extending this out you eventually get to “everything in ocaml”.

It works for them because they can hire people who can think. Obviously that’s a tiny fraction of developers. Yeah I said it.

[-]

madmars@reddit

I wonder if all these vanity projects will dry up now that we've entered a new era of AI slop and outright disrespect for engineering.

In fact, I also wonder if companies that do go against the herd and use something like OCaml will start feeling like they are in a worse position. Because AI knows a hell of a lot more JavaScript than OCaml. We could be entering a period where management selects for and only allows languages that AI is heavily trained on. You know, so they can get that push-a-button 10x engineer they have been dreaming about.

[-]

Loose-Potential-3597@reddit

A lot of big companies prefer to make their own tools and migrate to those to cut costs. I don't think it's always what's best for the developers, but it saves the money not having to pay for licensing and stuff I guess.

[-]

geeeffwhy@reddit

i think there is a whole spectrum of this behavior (or better yet, a dimension of an optimization surface), with Jane Street falling on one extreme. this is simply a trade-off calculation that all technology-users are making constantly.

i haven’t got nearly enough context to evaluate whether their calculation is optimal in this case, but i expect this calculation is dominating their decision-making. that and an emotional, cultural inertia that shouldn’t be discounted, either. people work off emotion first, calculation second.

[-]

Blothorn@reddit

Google doesn’t use one language for everything, but they did develop GWT to allow products with a Java backend to develop the frontend in Java too.

[-]

DecisiveVictory@reddit

Because FP is better.

[-]

780Chris@reddit

OCaml actually has a pretty great story for full stack web dev. With OCaml you can leverage the full JavaScript ecosystem on the front end, have a fully type safe system sharing types between frontend and backend, while also leveraging OCaml’s speed and new multicore functionality on the server. For the vim plugins I believe they just have OCaml bindings to Neovim’s Lua API, which is nothing new.

I don’t know if you’ve used OCaml but after working in it for a while and moving to other languages, you’re very likely to miss a lot of its features like pattern matching, expressive type system, speedy compiler, and instant static type checking. JaneStreet also maintain many libraries in the ecosystem and are doing exciting work in their fork of the compiler. It’s a great general purpose language and severely underrated.

[-]

Franks2000inchTV@reddit

"Use the best tool for the job" is not "use the tool for the job, that absent of other concerns is the most optimal tool available for this class of job."

You have to consider all the constraints before you decide what the best tool is.

The definition of the job includes:

- the timeline

- the resources available to yo

- the other people on the job

[-]

behusbwj@reddit

They like it. If it gets the job done then why not? Is Jane Street building advanced frontends that requires bleeding edge tech?

[-]

codemuncher@reddit

Front ends are not some neutral whatever piece of the stack.

The accurate display and entry of trading data is of critical importance. Imagine a front end bug that displays numbers rounded, or have them offset by several orders of magnitude?

Or shit, remember the mars robot mission that crashed because two modules were passing “int” but one side meant “feet” and the other meant “meters”? Guess what - ocaml gets rid of that bug class. Adding dimensions that can be verified at compile time is huge.

[-]

Appropriate_Mix5893@reddit

But by using ocaml-to-js transpiler you are not getting rid of js, instead you are just adding unnecessary obscure layer, that can itself be buggy. Using react which is battle tested by 100s thousands of devs around the world is way safer.

[-]

Equivalent-Wall4980@reddit

But by using ocaml-to-js transpiler you are not getting rid of js

No, but you are getting rid of humans writing javascript, which is the problem. As a compilation target javascript is fine, if a bit weird, but as a programming language it has a lot of nasty rough edges.

instead you are just adding unnecessary obscure layer, that can itself be buggy

The extra surface area is tiny. js-of-ocaml works by running roughly the entire normal compiler stack to the point of producing bytecode and then turns the bytecode into javascript. This bytecode is a small, simple language, so this is relatively simple (I've been using it for years and have never seen a bug in it). The rest of the compiler is where bugs are much more likely to show up (I have come across bugs here), but you're already exposed to that on the backend so cutting it out of the frontend is of limited value.

[-]

behusbwj@reddit

I was scared for a second that you were about to use this as an argument for using JavaScript+OCaml instead of just OCaml 😂

[-]

jjirsa@reddit

The accurate display and entry of trading data is of critical importance. Imagine a front end bug that displays numbers rounded, or have them offset by several orders of magnitude?

It's still ending up in javascript, because browsers.

[-]

codemuncher@reddit

By this logic we'd all be writing everything in machine code!

[-]

GimmeChickenBlasters@reddit

Front ends are not some neutral whatever piece of the stack.

What stack? An MVC? Nope. An SPA? Couldn't be any more neutral.

[-]

takuonline@reddit (OP)

Even if they like it, that should not be enough for them to keep this trend going. Common wisdom is there for a reason, you will be forced to follow the correct path over time. But if they have been around for 25 years, it must be working right? Like imagine how many people have joined and left the company, how much they have had to grow, yet non of these factors has changed this? Maybe we all can get away with using and learning one programming language that does it all

[-]

poincares_cook@reddit

Common wisdom applies to common scenarios. But their talent pool is anything but common, a lot of the common wisdom changes under those circumstances.

[-]

takuonline@reddit (OP)

This is a good take, thank you.

[-]

ATXblazer@reddit

If it ain’t broke

[-]

_-_-__@reddit

If it’s the one that they like and works for them, it is the correct path. This is a very junior SWE mindset

[-]

bamfg@reddit

common wisdom does not really apply to hedge funds, or big tech. those companies have the resources to gain an edge by investing large amounts into their own in-house tooling

[-]

ummaycoc@reddit

Languages aren't compiled; languages are mathematical constructs consisting of syntax and semantics. For some interesting relations, see https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections

[-]

UpsetKoalaBear@reddit

It’s clear what he meant, going from plain text to source code.

Posting this comment unnecessarily makes it look like you just took a compiler class at college.

[-]

ummaycoc@reddit

Please explain what they meant, then, if it is so clear.

[-]

UpsetKoalaBear@reddit

Because you clearly need me to explain colloquialisms to you:

He meant language as in the plain text you write on your computer to describe your application. He meant compiled language as in a specific flavour of your plain text that has to go through a compilation process in order to be run.

We know there’s more steps to a between this, you quite literally learn this when studying compilers in Computer Science. We also know there’s a whole lot of theory and applied mathematics that go into Computer Science. However, we’re not discussing Computer Science here are we?

We’re discussing why X company would use Y language despite Y language not seeming fit for the job.

It’s colloquial language. We know it’s not accurate nor descriptive but we don’t care because we can interpret what they mean. If you can’t, then I’m sorry.

[-]

behusbwj@reddit

Thank you, but I’ve learned to just ignore people like this. Ridiculous 😂 trust me it’s not worth your energy

[-]

ummaycoc@reddit

I think there’s a level of therapy you need that I can’t provide in a reddit conversation. You’ve put a lot of feelings into this and I hope you find a way to a better self.

Cheers.

[-]

UpsetKoalaBear@reddit

Bruh

[-]

ummaycoc@reddit

Okay. Again I hope you find your better, more fulfilled self.

Cheers.

[-]

lunacraz@reddit

interesting - i had the impression they actually used "regular" tech for FE, but i guess not!

[-]

Equivalent-Wall4980@reddit

https://blog.janestreet.com/why-ocaml/ would be a good place to start - even though it's about 10 years old, the same reasons largely apply.

I just learnt that Jane street uses Ocaml for pretty much everything.

Python has been growing in usage for years. I would hazard a guess that it's on the order of 10% these days - maybe 90% does fall under "pretty much everything".

This goes against my knowledge of, use the best tool for the job.

The "best tool" is very context-dependent. Jane Street does a huge amount of sharing across the firm, and it's incredibly valuable that anyone can use libraries written by anyone else, which is largely enabled by agreeing on a single language (there are mechanisms that allow calling between Python and OCaml so even the Python codebases get this power to some degree).

Also, OCaml is legitimately a very good language. Having worked pretty extensively in both OCaml and javascript, I'd claim that the former is better for a surprisingly wide variety of frontend tasks (although certainly not all of them).

Why would you want a mathematically proveable language on the frontend anyways.

Having a strong type system (and using it well) is useful in all domains I've worked in. You can eliminate a lot of potential bugs much faster (the compiler tells you, instead of e.g. you noticing when clicking around the UI) and refactor much more confidently.

[-]

RaCondce_ition@reddit

Ocaml is a more practical version of Haskell, and like Haskell, it appeals to academics who want to delve into types. Jane Street hired some dude straight out of an advanced degree and he really like Ocaml. It worked so well the company just stuck with it. Using niche languages like this also filters your applicants, so finding the kind of dev you want is easier, even if there are far fewer in an absolute sense. At this point it basically is the best tool for the job. It works for everything the company wants, and it makes everything provably correct, so why switch and worry about some weird long tail event?

[-]

takuonline@reddit (OP)

My point is not to switch, rather is to use the best tool for the task. Like l said, Facebook might mostly work with one language, but if they are doing frontend, they are going to use js. The same applies for python which can do "everything", but might not be the best tool for mobile development or game development for instance.

[-]

syklemil@reddit

using js-of-Ocaml library to transpile Ocaml to js

Honestly I'd expect compiling to wasm, but I guess they've been doing this longer than wasm has been a thing.

I also know that there is the argument that the js guys use to defend use of js on the backend saying that you have a single language for everything, but this is too much, isn't?

No no, I can only applaud anyone willing to bend over backwards to avoid writing anything directly in js. The day when js is only a transpilation target can't come quickly enough.

[-]

Equivalent-Wall4980@reddit

Honestly I'd expect compiling to wasm, but I guess they've been doing this longer than wasm has been a thing.

Exactly right. Last I heard the wasm version was pretty close to landing, though.

[-]

Mental-Work-354@reddit

They have about a thousand articles and tech talks talking about why the do it, and this question has been asked a million times already. Have you tried googling it?

[-]

takuonline@reddit (OP)

Thanks, l just found out about this actually.

[-]

INTERGALACTIC_CAGR@reddit

google?

[-]

bentreflection@reddit

hey wow this google thing is pretty neat

[-]

Smile-Nod@reddit

Just found out about it

[-]

beaverusiv@reddit

was pretty neat. I wanna go back to 2010

[-]

drakeallthethings@reddit

OP has probably been using bing and getting results on articles on F# instead.

[-]

panoply@reddit

They also hire very strong engineers who can make use of the advanced features of OCaml, and it serves as a recruiting advantage - it’s more interesting to write OCaml than most other common languages.

[-]

Agent281@reddit

Everyone is saying culture, hiring, and expertise so I'll just mention interoperability.

If you have a bunch of modules in OCaml and you want to use them on the front end then it makes sense to use the OCaml to JS compiler. Given that the company really likely strongly typed functional programming, it makes sense that they would want to reuse that logic and continue benefiting from their static types.

[-]

dashingThroughSnow12@reddit

Ocaml is a pretty fantastic language.

[-]

unlucky_bit_flip@reddit

FP is beautiful for HFT. FP is just beautiful

[-]

takuonline@reddit (OP)

Yes, l get that, but for everything though? Really. They have been around for like 25 years.

[-]

TRexRoboParty@reddit

What are the reasons not to?

What does "best tool for the job?" even mean?

I could argue Javascript isn't even the best tool for frontend development.

If it was, Typescript would never have existed. It just compiles down to Javascript because that's what browsers need.

Using OCaml to compile to JS isn't so different - but it has a much better type system and stronger functional features.

[-]

schmerg-uk@reddit

OCaml has been around a while (esp if you trace it back to ML which was being taught in academia back in the 80s) and then it influenced Haskell and it's the basis of F# (which started off as basically OCaml ported to .NET by Don Syme within Microsoft Research in Cambridge and can also be used to generate javascript or GPU code etc)

And for certain types of trade modelling, functional languages have real advantages (rather than in house developed so called payoff languages) in being fundamentally declarative rather than imperative.

So if your core devs already think in a mostly immutable functional way, why wouldn't you leverage that for other stuff?

[-]

drakeallthethings@reddit

Jane Street is an edge case company using an edge case language. That makes perfect sense. The things they need are accommodated best by OCaml. Other companies have different criteria. I also think you seriously underestimate OCaml’s frontend infrastructure. I’m not aware of what Jane Street specifically is using but something like eliom is pretty slick if your app meets its use case.

Don’t take this the wrong way but they are using the best tool for the job. You just don’t understand the job.

[-]

zoddrick@reddit

ocaml's match statement is something i wish other languages had.

https://ocaml.org/manual/5.3/patterns.html

[-]

drakeallthethings@reddit

I love pattern matching. It highlights one of the major strengths of ml-style functional programming: it’s SO easy to read.

[-]

tikhonjelvis@reddit

luckily mainstream languages are getting real pattern matching, like Python since 3.10

[-]

PhillyThrowaway1908@reddit

They don't. Sure they are huge proponent of OCaml but if you look at their job listings there's plenty of python required for anything ML-related, and I'm assuming they're doing some backend things in Rust considering they are a sponsor of the Rust Asia conference.

[-]

EvilTribble@reddit

If you choose a niche technology for your platform, you lose the ubiquity of people who are aware of that platform, but you gain in that every person who is willing to work in that niche technology is necessarily going to be a person who is willing to learn.

If the niche has some intrinsic competitive advantage then its a no brainer.

I saw a similar case with a company where they didn't want an office full of java drones so instead they used clojure.

[-]

we_swarm@reddit

Here is one perspective I have not seen discussed here yet. There are tradeoffs with with their language decision that attempt to make their engineering org more efficient.

https://www.youtube.com/watch?v=sl1UQXgtepE

[-]

Mrqueue@reddit

Smart people do dumb things all the time

[-]

defunkydrummer@reddit

This goes against my knowledge of, use the best tool for the job. (...)

This does not make sense to me.

So, do you know OCaml? Have you at least tried to read about that programming language?

If you would, perhaps you could have found the answers yourself.

OCaml is one of the best general-purpose, production-quality programming languages available today.

[-]

vegetablestew@reddit

Started as ocaml shop. Strong culture around fp. Has enough strong engineering talent to take some extra steps and still make things work. Keep to keep talent engaged with problems that are not "routine".

Or they know something we don't about ocaml web dev.

[-]

tikhonjelvis@reddit

Or they know something we don't about ocaml web dev.

This is somewhat true in the sense that the incremental computing abstraction that they built their web framework on is both remarkably effective (not just for UI!) and not known widely outside the programming languages research world.

[-]

vegetablestew@reddit

Interesting. Do you have a link to a talk or blog I can take a look at by any chance?

[-]

tikhonjelvis@reddit

I haven't listened to it, but they did a podcast episode about their incremental UI framework

For incremental computing more generally, I don't know of a good intro off-hand. It's an idea I see pop up over and over—it's an abstraction that can unify UIs, simulations, evaluating large mathematical models and even build systems—but I only got an intuition for it after seeing a bunch of different things follow the same pattern. If you want to find more, you could try searching for "incremental", "adaptive" or "self-adjusting" computations.

One of my favorite papers is Build Systems a la Carte which talks about how different build systems are all doing similar sorts of incremental computation, and they reference some of the foundational research in the space. So if you're not averse to reading some academic papers, starting there and following some of the citations would be a reasonable approach.

[-]

vegetablestew@reddit

Thanks. I'll check those out.

[-]

appoloman@reddit

It's possible they prefer people who prefer Ocaml/functional programming, in a similar line of reasoning that Linux rejected C++ for so long, they didn't want mainstream programmers contributing.

[-]

CumberlandCoder@reddit

I asked Claude this question after watching the same talk
https://claude.ai/share/6849b489-20ee-49fc-a494-3c500a9a8821

[-]

ummaycoc@reddit

They may very well still be using the best tool for the job. Best is relative. Maybe it makes whatever they want to do easiest. Maybe it gives them something else. Lots of maybes.

But overall for a lot of work different choices are within a nice range of utility of one another. And if someone already made a library or tool to do the conversion, the differences shrink.

[-]

tikhonjelvis@reddit

they have a lot of talented developers and are very smart people, which makes this even more confusing for me

How is that confusing? I would say that Jane Street continues to use OCaml exactly because they have a lot of talented developers. They're willing to build way more in-house than almost any other company, and that gets them a disproportionate return on their engineering efforts.

Tools that are designed internally, just for yourself and with good taste, are qualitatively different from tools designed as products for other people to use. Jane Street has still been the single best example of this that I've seen.

Now, this is all based on an internship from 10 years ago, but my impression was that their internal tools and ecosystem were amazing—and that was back when they had like 100 engineers. Writing everything in OCaml lets you develop and share better abstractions and have everything integrate super smoothly.

For frontend in particular, their incremental computation framework provides a much nicer, more expressive foundation for UI code than React and friends. The point is not that OCaml is "mathematically provable" (it really isn't) but that it is more expressive than mainstream languages.

[-]

latkde@reddit

OCaml is a really good programming language that does lots of things really well. It has many advantages of Haskell (ML style type system that makes it easier to write correct code), but is much more pragmatic – support for OOP-ish patterns, fairly low level and predictable performance. Nowadays I think most of its niche is better served by Rust (performant programming at different scales of abstraction, with strong support for functional patterns), but OCaml is much older.

The downsides are obvious: small ecosystem, small talent pool. But depending on what you do, this doesn't matter. If large parts of your ecosystem are in-house, and if your focus is on business logic rather than integrating third party components, you don't need a vibrant external ecosystem. This is like the antithesis of JavaScript. Small talent pool also doesn't mean empty talent pool. OCaml isn't Cobol, people actually use it voluntarily.

Then:

are there strong grounds for moving away from OCaml? Concrete dissatisfactions?
are there strong pull factors towards other technologies?
what are the costs of a migration? Rewrites are absurdly expensive, and a multi-technology strategy a la microservices also has costs.

While I wouldn't recommend that a new company bets on 100% OCaml in 2025, I totally get why a company that has decade long success with OCaml doesn't see a pressing need to stop having success.

[-]

alwaysmpe@reddit

"Use the best tool for the job". What's your metric of best?

They're not a software company. They're a trading company. Ocaml is easier to read for the traders which is (I was told when I interviewed) one of the reasons they favor it. I didn't get the job but it was a really positive interview experience.

[-]

timwaaagh@reddit

I mean if its possible and there are no huge issues then its obviously better to have the same language for all software. Using the 'best tool for the job' is a problem because it means every Engineer needs to learn many languages. Meaning they will learn none very well.

[-]

Icanteven______@reddit

My college roommate has been an engineer at Jane Street for 15 years. I remember the first day of school (Comp science program) he was showing me the Tetris clone he made using Haskell. Dude LOVES functional programming.

He got an offer and was like “I can do functional programming AND make bank??”

The answer is they are succeeding and can do what ever they want. There’s clearly demand for jobs that offer functional programming languages, and the folks that are attracted to them tend to love it. Passion matters.

[-]

huuaaang@reddit

Programmers don't always choose the "best" tool for the job. A lot of time it's just whatever they know and like using. Maybe even most of the time. If it works, it works. But they might have some long term issue replacing developers. Finding experienced Ocaml devs can't be easy.

[-]

toblotron@reddit

I've heard there is a saying that's supposed to come from Google: "Different languages in the house? Sure! One per 10000 developer works just fine" :)