How Jane Street is making OCaml the new Rust
The love affair between the programming language Ocaml and proprietary trading firm Jane Street is a storied one. Jane Street's departure from the industry standard of C++ has always presented an exciting challenge for quantitative developers on the buy-side. Languages are always evolving, however, and Jane Street wants to steer its favorite language in the same direction as another low-level cult favorite, Rust.
A Jane Street blog post yesterday from Max Slater, a software engineer who joined the firm as a graduate, discussed "oxidizing" the language to emulate Rust when it comes to the mutability of its values. "One of Rust’s primary design goals is to entirely forbid shared mutability," Slater says, "which it achieves by only allowing mutable values to be referenced uniquely." By comparison, he says OCaml, "records containing mutable fields are relatively common" which makes handling data difficult.
Ocaml emulates this by marking individual fields as exclusively mutable, though there are still notable differences. Slater says that "in Rust, variable bindings are marked as mutable upon declaration." Though the types of variables in OCaml are akin to those in Rust (e.g. a unique variable is similar to a value in Rust while an exclusive variable is similar to a mutable reference), Slater says "OCaml's references are not parameterized over lifetime variables," meaning "uniqueness doesn't lead to higher-order polymorphism."
Another proponent of Rust's influence is Richard Eisenberg, a functional language designer at Jane Street who spoke on its podcast, Signals and Threads, about his efforts in the space. For Eisenberg, it is not what Rust adds that's impressive, rather it's what it takes away: garbage collection (GC). While he notes that GC is "fantastic" in its ability to "program without worrying about low-level details for most programs," eschewing it gives the programmer a "fine level of control." This is similar in premise to what low-latency Java developers do, bypassing the JVM and off-heaping memory to areas not subject to the GC.
"In Rust we are forced to think about memory allocation, and deallocation at every point in time," Eisenberg says, which "gives us this fine level of control, but comes at a real cost." This is why, when taking inspiration from Rust's design, Eisenberg is focused on "adding that finer level of control, but just where we need it."
Have a confidential story, tip, or comment you’d like to share? Contact: email@example.com in the first instance.
Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)