The Rabbit Hole

Lately I’ve gone completely down the OCaml rabbit hole.

Something about the language has pulled me in. It just feels different from what I normally work with. Refreshing.

The problem is that OCaml exists in a strange corner of the industry. Outside a few communities, most developers barely think about it.

One place where they absolutely do is Jane Street.

And when I say they care about OCaml, I mean they really care about OCaml. Not just as a language they happen to use. As infrastructure worth investing in at every level:

  • their own compiler extensions,
  • custom tooling,
  • internal frameworks,
  • performance tracing systems,
  • research partnerships,
  • even their own trained AI models.

One late night. Okay, literally last night. I fell into a rabbit hole that started with a YouTube video and ended with me questioning my entire understanding of software engineering careers.

At some point I found myself scrolling through job titles I didn’t even know existed.

Domain Specific Language Engineer.

Programming Language Engineer.

Language and Runtime Engineer.

OxCaml Educator.

Low Latency Engineer.

I understood every word. That was not the problem. The problem was I had never worked anywhere with the scale or the engineering culture to justify roles like that existing.

And this was not at Microsoft or NVIDIA where you would expect it.

It was at a trading firm.

Where I Come From

My first real job was at a soccer store. Cleats, shin guards, jerseys. Good times. Before that faded, I ended up working at a tire shop before college. Lug nuts, alignments, busted knuckles. Also good times. Then at 19, I started at the company I’ve been at ever since. And honestly, there’s a lot of cool in-house engineering there. Real systems. Real problems. Real impact. I’m not knocking it at all. But this felt different. Not bigger in the normal corporate sense. Different in how deeply engineering itself seemed to matter.

The Realization

The deeper I dug into Jane Street, the less it felt like “a company that uses OCaml” and the more it felt like a company that treats engineering itself as the product.

Most companies use programming languages.

Jane Street invests in OCaml like it is critical infrastructure.

They built OxCaml, their own set of extensions to OCaml focused on performance engineering. They helped support OCaml Labs at Cambridge. They released over a million lines of open-source tooling. They built their own code review system, their own build tooling, and even performance tracing systems designed specifically for low-latency engineering work.

And OxCaml itself is kind of absurd.

It adds things like:

  • fearless concurrency integrated into the type system,
  • memory layout control,
  • SIMD optimizations,
  • allocation management for reducing garbage collection pressure,

while still maintaining compatibility with existing OCaml code.

That is not a side project.

That is a company hiring entire teams to work on their programming language. Because it matters that much to them.

Engineering at a Different Scale

And it doesn’t stop at programming languages.

At some point I ended up watching how they went from six Dell boxes to building a purpose-built AI data center in Texas with thousands of liquid-cooled GPUs. Then I learned they committed $6 billion to CoreWeave for next-generation AI compute including NVIDIA Vera Rubin chips.

Then I learned they created internal systems where teams literally bid against each other for GPU allocation time using something called “hive bucks.”

That sentence alone sounds fake.

But that is the point. At a certain scale, companies stop adapting to existing tools and start building everything themselves.

  • Custom languages.
  • Custom runtimes.
  • Custom infrastructure.
  • Custom scheduling systems.
  • Custom tooling.

Entire engineering disciplines that most developers will never see.

If you want to see what their AI engineering looks like in practice, John Crepezzi gave a talk that gets into the details. And if you want to see the data center with your own eyes, Dwarkesh went inside it.

Why It Matters

The weirdest part was not feeling intimidated.

It was realizing how small my idea of software engineering had been.

For most of my life, “software engineering” mostly meant:

  • web apps,
  • internal business systems,
  • cloud infrastructure,
  • mobile apps,
  • maybe game engines if you were lucky.

Then suddenly I am reading about compiler engineers, runtime specialists, type-system research, memory-layout optimization, low-latency systems, and people whose full-time job is making a programming language faster. A language most developers will never touch.

There is an entire layer of the industry that I did not know was there.

That is why this stuck with me. Not because I want to become a quantitative trader. Because I stumbled into something that completely changed what I thought this field even was.

The Point

Software engineering is a much bigger world than most of us experience day to day.

Some companies treat technology as a tool.

Others treat engineering itself as the product.

Somewhere out there are teams building compilers, runtimes, tracing systems, scheduling infrastructure, and entire programming language ecosystems that most people will never hear about. All because a few milliseconds actually matter at their scale.

I don’t know where this fascination with OCaml eventually goes. Maybe nowhere.

But I do know this:

It has been a while since a rabbit hole reminded me how much I do not know and how many cool things are sitting in YouTube videos, podcasts, and papers waiting to be found.

AI helped with editing and formatting. The research, the opinions, and the rabbit hole are mine.