Yaron Minsky

Me too! (But Max knows more about it than I do.)

Most companies be like “We daren’t go functional, we might not be able to hire”.

Jane Street be like “Hold. Our. Beer.”

And if you want to learn more about OxCaml itself, take a look here:

oxcaml.org

We're going to be at SPLASH/ICFP in Singapore, so if you're going, come talk to us! Richard Eisenberg is an especially good person to ask, but a lot of us will have useful context on this.

OxCaml Educator :: Jane Street Jane Street is a quantitative trading firm and liquidity provider with a unique focus on technology and collaborative problem solving.

Excited to say that we're looking to hire someone to focus on OxCaml education! We're doing enough to change the language that we have a pretty big internal education task ahead of us, and we want to hire someone to focus on it!

Please share this with others!

www.janestreet.com/join-jane-st...

YouTube video by Jane Street Hacking OCaml

A fun talk about...hacking OCaml. Basically, what you get when you supercollide a systems-y OCaml developer and a CTF.

www.youtube.com/watch?v=SV9V...

The Oldest Constitutional Question | Interview: Richard Primus Originalism through the lens of sola scriptura.

On Advisory Opinions, Sarah Isgur and David French speak with me about enumerated powers. The segment begins 43-44 minutes in, depending on format. This was a good conversation among people with different approaches to constitutional interpretation.

thedispatch.com/podcast/advi...

They should know the difference between TeX and LaTeX, so they could hate Lamport less and Knuth more.

Clearly, the reason for the AI work is to build an AI capable of porting from Latex to Typst.

"we need a manhattan project for AI" no what we really need is a manhattan project for porting every math TeX package to Typst (and please start with mathpartir)

I should get them to read the part time parliament, and see what they think of Lamport then.

(discussing Typst)

I've raised my kids well, I think.

Actually, maybe it's the only game in town if you want any two of those three properties...

I'm pretty excited about the possibilities with Mojo, and I think more people should check it out. If you want a language that is pleasant to write in, that lets you write speed-of-light kernels, and lets you write kernels portably, it's kind of the only game in town.

I think it's a great approach, and it turns out that it's something we're doing in OxCaml as well (though it hasn't quite hit production yet.) And you can see some early work in this direction with dialects like MetaOCaml: okmij.org/ftp/ML/MetaO...

Template error messages are pretty tough, and the compile times are rough too. Mojo provides typed metaprogramming as a first-class language feature, similar in some ways to the approach Zig takes.

In CUDA, libraries like Cutlass use template metaprogramming to do this adaptation. But that's a problematic approach!

But the constraints when targetting GPUs are really different! A critical thing when targetting GPUs is being able to adapt your code not just to the shape of the problem, but also to the weird and idiosyncratic shape of the hardware!

YouTube video by Jane Street Making OCaml Safe for Performance Engineering

Mojo is very much a language designed for performance engineering, which is an idea that's close to my heart. Indeed, a lot of the work we've been doing on OCaml is about providing the kind of control you need for performance work.

youtu.be/g3qd4zpm1LA?...

Signals and Threads Podcast Listen in on Jane Street’s Ron Minsky as he has conversations with engineers working on everything from clock synchronization to reliable multicast, build systems to reconfigurable hardware. Get a pee...

A new episode of Signals and Threads just dropped! This one is an interview with Chris Lattner talking about Mojo, a new-ish language for GPU programming that's aiming to be an alternative to the CUDA stack.

signalsandthreads.com/why-ml-needs...

Will's research doesn't attack these kinds of questions, and instead focuses on smaller scale questions that are easier to study in a rigorous way. Which is great! But I nevertheless pine for rigorous answers to the bigger questions.

I'm somewhat dismayed by the methodological difficulties here. E.g., how do the major improvements to PLs over the last 50 years, like memory safety, GC, rich type systems, type inference, etc, influence productivity? We don't know!

This was a great talk from Will Crichton. I think Will's approach to approaching questions around language tooling and teaching is compelling, though I wonder how far the approach can scale!

youtu.be/R0dP-QR5wQo?...

If you're looking for a fun and challenging way of spending the summer, consider applying!
www.janestreet.com/join-jane-st...

What the interns have wrought, 2025 edition Yet again, we’re at the end of our internship season, and so it’s time to summarize whatthe interns were up to!

I just finished our yearly roundup of this year's intern projects, and it was a real bumper crop! Lots of fun projects, and some cameos from OxCaml...

blog.janestreet.com/wrought-2025/

I also think he nailed something important about how Iron, our code review tool, encourages a collaborative approach, and the mix of social and technical conditions required for that to work.

I do think Rudi's experience led him to overstate how purely functional our codebase is. There are lots of places we use an imperative style for performance reasons.

Just ran across this old post from a former intern about Jane Street's approach to programming and code review. I thought it was a pretty accurate, and I think captures something important about how OCaml's design makes code review easier and more effective.

digitalfreepen.com/2017/01/07/j...

This will remove so many unnecessary OCaml functors from our codebases. My rough rule of thumb is that if a functor is not applied more than once in a codebase, it doesn’t need to be a functor. Parameterised libraries lets us easily do one-shot reuse of existing modules in a different context.