Does Jane Street use other programming languages aside from OCaml?
I am very interested to know if OCaml can do everything.
1 Like
But Jane Street does not do “everything” so even if the answer to your first question was yes, it wouldn’t solve the second one.
OCaml is a reasonable choice if you don’t need the last milligram of performance and can afford the overhead of garbage collection. That’s not to say that there aren’t sometimes reasons not to use it when it would normally be appropriate (say, lack of availability of library support or some such.) Most (say 95% or more) of applications fall in this category.
Our three major programming languages, in order of use are: OCaml, VBA and Python.
OCaml is the tool of choice for serious software systems, and that includes highly-performant systems that do almost no garbage collection and can consume and emit packets in single-digit microseconds. OCaml is a surprisingly hospitable home for such applications, though it takes some time to learn how to build them properly. We of course also build all sorts of more complex systems that make intense use of the GC. Beyond that, we use OCaml for building command-line tools, big transaction-processing systems, web-uis, data processing and machine learning tools, and more.
VBA is for extending Excel spreadsheets. VBA isn’t great, but Excel is, and the integration between the two is very good.
Python is our data-munging scripting language. Jupyter notebooks and great libraries for data manipulation, machine learning, and visualization are what motivate our choice here, in addition to the fact that it’s easy to pick up for people with little programming background.
There’s a bit of bash and ruby as well, and some F# and C# for windows-side work, and I think that mostly covers it.
y
15 Likes
The techniques you have pointed to in the past for doing such things remind me a lot of the techniques I’ve seen other people use in the past to avoid allocating in other garbage collected languages. I personally find them unnatural enough that I’d probably turn to a language like Rust instead, but I know that they’re effective for some people. (I once saw an ECN (which for those that don’t know is a sort of electronic stock exchange) built in Java with essentially no allocation at all so it could avoid garbage collection — it worked very well and made the creators a not insignificant amount of money, but again, I wouldn’t have written it that way. The fact that they’re wealthier than me means it’s difficult for me to tell them they were wrong.)
BTW, I’ve said it before, but these days, my tastes are: if it can garbage collect and doesn’t need the last few percent of machine performance, use OCaml. If it can’t garbage collect or needs to be insanely efficient, use Rust. But I suspect that other people (including at Jane Street) would argue with me about this. 
A key advantage of OCaml in this space is that you can do both on the same codebase. For a complex organization, being able to do many things in the same language means you can share tools, libraries, techniques, developers, etc, between projects. If all I was doing was building zero-alloc packet processors, I might be more inclined to use Rust (though I don’t really have enough experience, having never used Rust in anger). For the complex mix of things we’re actually doing, I’m very happy using OCaml.
2 Likes
I believe that was the argument at the ECN in question as well, and I suspect it’s probably correct enough; if programmer productivity is highest using the same language lots of other things in the organization are written in, then that might very well be the right choice even if the language isn’t really built for the use case. There’s no single right answer on things like this — that which works well for the company is what’s “correct”.
That said, I think in general, if one was selecting a language for the use cases in question absent issues like what an organization was already familiar with, a garbage collected language is probably not the first choice in such cases.
What I think we all agree about OCaml has a uniquely good set of properties for “almost all” programs, given that “almost all” programs do not have very tight realtime constraints and that both programmer productivity and performance is excellent in the language. Whether this is also true of the tiny minority of programs we’re currently discussing (which I’ll note “most” programmers never have to write!) is not that important. Furthermore, given that so many organizations seem to comfortable with the performance of writing enterprise application in something like Python or Ruby, there’s no dimension along which OCaml isn’t a strict win over those.
Do you have some Excel->OCaml bridge, or do you exchange CSV between two?
3 Likes
I’m suddenly very curious about this. My company has an OCaml library wrapper around Python to convert Excel to CSV so I’d be very happy if something better exists…