Jane Street is looking for new build system engineers! I’ve worked in this team for two years and I love the job. Here is why:
You frequently change focus from low-level work, like debugging a weird file-system issue, to high-level work, like designing a cloud build cache.
Your colleagues are amazing. If you’re like me, you’ll feel like an imposter in most conversations but it’s OK since everyone is kind and helpful, so you’ll learn something new every day.
Most of your work is open-source and benefits the wider OCaml community.
For balance, let me also say a few words about challenges.
Build systems accumulate years of knowledge of many people on how to get things done. When this knowledge goes out of date, you are often the only person to fix it. For this reason, build systems work can be daunting.
It’s far from our core business, so you don’t get to work on any of our cool trading systems. Your role is to empower others.
Our team is small, so we may have to turn down some good candidates. However, please don’t get discouraged by this! If in doubt, send me a message and we’ll chat.
There is no remote work for now.
To apply, follow this link and mention the build systems role in your application.
Our plans for 2022 include: implementing cloud builds in Dune, better integration with other tools like IDEs and the OCaml compiler, and making Dune even faster than it is today. To learn more about our work, listen to this podcast.
And feel free to message me or @jeremiedimino if you have any questions!
I totally loved your “Build Systems ala Carte” paper (which you coauthored with Neil Mitchell and SPJ).
That paper was written in Haskell and I assume much of your work previously was in Haskell. Now that you are in Jane Street I would assume most of your work is in OCaml.
It would be interesting to get your experience on the transition into OCaml. What do you find good/delightful in OCaml generally speaking (and in comparison with Haskell) and what would you like to change in OCaml?
(I hope that this not too off-topic on this thread. You can also open a fresh thread if you wish to reply)
This does seem a little off-topic but I don’t mind =) I’m glad you loved our paper!
Indeed, Haskell was my first language of choice before joining Jane Street. After writing a lot of OCaml in the last two years, I’ll now choose OCaml for any non-toy project. It’s worth saying that I continue to maintain several Haskell projects, and I still enjoy writing some little experiments in Haskell (and also Agda).
Here are the OCaml features I love:
Modules. I define a lot of modules. It’s great to not be restricted by Haskell’s one-module-per-file rule. I also love not having to mess around with module import lists.
I got really addicted to named arguments. This feature makes it so much easier to read and write code. I hope Haskell gets named arguments too some day.
OCaml’s records… just work. Haskell is fixing records too – perhaps, the latest release (GHC 9.2.1) finally solves this long-standing problem but I haven’t tried yet.
I like let rec. I think it’s the right call to make let non-recursive by default.
Finally, I prefer strict evaluation by default. Pervasive laziness let’s you do some really cool things, no doubt, but… all my Haskell programs have memory leaks. I just know that. And when I try fixing them, I often have to turn an elegant Haskell program into some cryptic bang-annotated meh. I prefer my lazy bits to be inelegant in OCaml because, as it happens, I don’t need laziness as often as I thought.
I think OCaml’s build/compilation times are much better, which makes me more productive. (I’ve never done a proper comparison though.)
Of course, there are some things I don’t like about OCaml:
No type classes means I often need to be more explicit that I’d like. Being explicit is not always a bad thing, but this typically bites me during a long debugging session where I just can’t print out the thing I want, which slows me down. Fortunately, there is some work on fixing this.
This is a little thing but it bothered me since day 1 and still bothers me: writing the type parameter before the type name, as in string option list. I know this is never going to change, which makes me a little sad. But maybe I’ll get used to it eventually. Yoda become maybe I will!
The lack of higher-kinded types means that some abstractions that are easy in Haskell, like traversable containers, become harder/less elegant in OCaml. This paper does a good job describing the problem.
Yes, the “ala Carte” paper was one of most the eye opening papers I’ve read. I underestimated the beauty of build systems in general and did not find them interesting – that was before the paper!
Additionally, the way the essentials of each build system were expressed in code is a testimony to the modelling ability of the Haskell language (and of course the authors).
It would be interesting to see if the same paper could be written with OCaml and still be “practical” to read. The paper uses a lot of non-trivial features of Haskell so its not going to be an easy task, I guess.
I personally find Haskell beautiful but eminently impractical.
This is the crux of the issue. Yes, Laziness does lead to a lot of inadvertent leaks and it seems like a never ending game to stem it in large, long running Haskell programs with evolving code bases.
It seems pointless that one would spend all that time doing fancy type jugglery to get compile time guarantees but then get leaks during runtime (which is, to me, a total anti-thesis of compile time guarantees!)
One interesting thing that I find in OCaml vs Haskell: SPJ tends to mainly concentrate on the typing side of Haskell while Xavier Leroy seems to spend on a lot of time on the runtime/performance side of OCaml. This difference in emphasis by some of the major personalities in both languages reveals a lot! In general while Haskell has a lot of advanced and cutting edge features, I find OCaml as a more balanced, reliable and responsive system overall.
Is it because the way the company works, a managerial choice, or for some legal reasons (like finance companies need to track the activity of their employees)?
Thank you @snowleopard for a very balanced Haskell/OCaml comparison. I could have written it myself
I know. This comes straight from Milner’s original LCF ML design. You’ll find the same oddity in Standard ML. My guess is that if you’re a native English speaker, “an integer list” rolls off the tongue more easily than “a list of integer”, hence “int list” instead of “list(int)”. As a native French speaker I would say “une liste d’entiers” (list int), and as a mathematician I would write “list(int)”.
Interesting to know that this choice goes all the way back to LCF ML, so a few years before I was born! By the way, in Russian, “список чисел” and “чисел список” (“список” = “list”, “чисел” = “of numbers”) are both grammatically correct although the first one is used more often. I guess, as a native Russian speaker, I should be less concerned about the word order.
I should clarify something about remote work: we have virtually no fully-remote roles, but do expect to provide some work-from-home flexibility depending on the team and role – in any case, we should talk about it more if you’re interested in the role!
