I wonder if Jane street uses OCaml because they have an unfair advantage (ie did minsky have had an important role in enabling an organization around it and it requires someone special?) or if there’s a recipe here for adopting FP.
They were having a lot of trouble trying to productionize their Excel sheets into Java trading software. They didn’t feel confident about its correctness. Minsky was a CMU grad, familiar with OCaml, and he tried prototyping that software in OCaml to see if it could be better. It turned to be good enough that they productionized it. Jane Street has a very high aversion to risk from programming errors because they can quickly sink the entire company (see e.g. Knight Capital). I don’t think that can be replicated into a general formula. However, OCaml does offer many other benefits for workaday commercial software which can make it a good pitch.
This seems like a pretty complex way of managing lifetimes and scopes. It’s not obvious to me that this is simpler or more powerful for the programmer than an ownership and lifetime model.
It seems like this was chosen because it was simpler for the compiler implementer.
Modes are a lot less powerful than explicit lifetimes, but substantially simpler. It’s a feature that covers common use cases, but cannot express a lot of things that you can express in Rust: modes give you no way to say that a value is “owned by” the data structure it resides in, for example — as a first approximation all you’re saying is that some values are allocated on the stack and some on the heap.
It’s important to remember that OCaml is a garbage collected language, and the garbage collector is still doing all of the heavy lifting for non-local allocations. This feature gives programmers a way to opt out of garbage collection (and the corresponding performance overhead) for values that can be statically proven to be short-lived — it’s not an alternative solution to memory management in OCaml.
This feature gives programmers a way to opt out of garbage collection (and the corresponding performance overhead) for values that can be statically proven to be short-lived
It does seem quite nice for that. Though that makes the Rust comparison feel like a red herring to me, since they are not that similar in overall design. At least from my read, this OCaml feature is a lot more similar in scope and intent to something like Common Lisp’s dynamic-extent allocations. Though one important difference is that Common Lisp doesn’t require the implementation to verify these annotations statically (the implementation is allowed to assume that the programmer has correctly specified that the value does not escape).
I think the static guarantee is the interesting bit (and the reason that the comparison to Rust makes sense). It’s not just allocating values on the stack, but allocating values on the stack and guaranteeing that references to those values can’t outlive the stack frame. (Speaking loosely here, since the allocation regions aren’t literally the call stack, and exclaves mean you can allocate in other regions, but you get it.)
I wonder if Jane street uses OCaml because they have an unfair advantage (ie did minsky have had an important role in enabling an organization around it and it requires someone special?) or if there’s a recipe here for adopting FP.
They were having a lot of trouble trying to productionize their Excel sheets into Java trading software. They didn’t feel confident about its correctness. Minsky was a CMU grad, familiar with OCaml, and he tried prototyping that software in OCaml to see if it could be better. It turned to be good enough that they productionized it. Jane Street has a very high aversion to risk from programming errors because they can quickly sink the entire company (see e.g. Knight Capital). I don’t think that can be replicated into a general formula. However, OCaml does offer many other benefits for workaday commercial software which can make it a good pitch.
This seems like a pretty complex way of managing lifetimes and scopes. It’s not obvious to me that this is simpler or more powerful for the programmer than an ownership and lifetime model.
It seems like this was chosen because it was simpler for the compiler implementer.
What I do like is how explicit this all is.
Modes are a lot less powerful than explicit lifetimes, but substantially simpler. It’s a feature that covers common use cases, but cannot express a lot of things that you can express in Rust: modes give you no way to say that a value is “owned by” the data structure it resides in, for example — as a first approximation all you’re saying is that some values are allocated on the stack and some on the heap.
It’s important to remember that OCaml is a garbage collected language, and the garbage collector is still doing all of the heavy lifting for non-local allocations. This feature gives programmers a way to opt out of garbage collection (and the corresponding performance overhead) for values that can be statically proven to be short-lived — it’s not an alternative solution to memory management in OCaml.
It does seem quite nice for that. Though that makes the Rust comparison feel like a red herring to me, since they are not that similar in overall design. At least from my read, this OCaml feature is a lot more similar in scope and intent to something like Common Lisp’s
dynamic-extentallocations. Though one important difference is that Common Lisp doesn’t require the implementation to verify these annotations statically (the implementation is allowed to assume that the programmer has correctly specified that the value does not escape).I think the static guarantee is the interesting bit (and the reason that the comparison to Rust makes sense). It’s not just allocating values on the stack, but allocating values on the stack and guaranteeing that references to those values can’t outlive the stack frame. (Speaking loosely here, since the allocation regions aren’t literally the call stack, and exclaves mean you can allocate in other regions, but you get it.)