Understandable how you'd get that impression, but it's off the mark. We do lots of "ordinary" programming that looks nothing like waiting a compiler. Data analysis, high performance packet processing, log analysis, UI work, you name it.
We use OCaml as a general purpose tool, and it really excels in that role.
Interesting. I've always wanted to dig deeper into OCaml but haven't really had the chance to do so yet. I really enjoy a lot of what I've read about your work with OCaml and it looks like a great place to work for someone like me (4 years of automated trading experience in futures markets and a love of strongly-typed functional programming), but alas I'm not in a position to relocate from Seattle.
I think the disconnect here is that for much of the world these days, "ordinary" programming is a backend for a web or mobile app, using REST (or maybe GraphQL if you're avant garde). I'm sure Jane Street does lots of web stuff too, but I haven't see a bunch of Core libraries to do, for example, a CRUD app on Postgres in the cloud somewhere.
But we did, though we used the term "algebraic effects". And while it's being actively worked on, it hasn't landed yet, so I don't know that I'd call it recent...
Indeeds, sorry. I searched for "handler" and saw no hit. It's a very interesting topic for me. I wouldn't call them 'algebraic' anymore because the way they are done in OCaml the algebraic aspects are fairly obscured. It's the handling semantics which is critical. Anyway, this is besides the point.
If you're interested in understanding more about what Hardcaml is trying to achieve, you might enjoy this interview with Andy Ray, the primary author of the library:
A few thoughts, since some things have changed since that post was written:
First, the tooling limitations that I mentioned in the article have gotten a lot better. In particular:
Merlin now provides IDE-like functionality for your editor of choice (including code, vim, and emacs).
Also, Dune is an excellent build system for OCaml that does an enormous amount to simplify the build process, and tie a bunch of different tools in the ecosystem together. One great thing about Dune is it does a lot to unify the experience we've long had inside of Jane Street with the open-source OCaml experience. It's really a big upgrade.
We've also made some progress on debugging tools, like the spacetime allocation profiler. There's also active work on making GDB/LLDB debugging in OCaml really first class.
Also, OCaml has had some major industrial uptake. Notably, Facebook has several major projects built in OCaml (Hack, Flow, Infer) as well as their own syntactic-skin-plus-tooling on top of OCaml, in the form of Reason. Reason has gotten a lot of traction in the webdev world, which is awesome. Bloomberg, and Docker are some other big names that have real dependencies on OCaml, along with some more names you probably don't know like Ahrefs, LexiFi, and SimCorp.
People sometimes feel like Jane Street is the only real user of OCaml, so they imagine that Jane Street's needs are the ones that drive the language priorities. So, the thinking goes, if you're not a trading firm, you should look elsewhere. But this is the wrong picture. First, there are other serious users, as discussed above. Besides, the community doesn't just roll over and do what we say. If you don't believe it, go and see how often our PRs to OCaml get rejected.
And even our interests in the language have grown beyond what you might imagine a trading firm would care about. We use OCaml for building traditional UNIX system software, like MTAs, for designing hardware (via HardCaml), and for building dynamic browser-based applications (via Incr_dom).
For sure, there are still challenges of being a minority language (and there's still no multicore GC, despite some exciting progress). But I believe OCaml is a yet better choice than it was in 2011 when I wrote the article.
And, shameless plug, if you're interested in seeing what it's like using a functional language at scale for solving real problems, well, you can apply...
I'm 27 years old and I haven't prioritized my career as much as I could have. For example I've joined teams that allow me to work remotely from countries of interest instead of searching for ones that had the best environment for growth as a software developer.
I'm not unhappy at all with the choices I've made so far, but my goals in life are changing and it's making me wonder what it takes to be accepted into companies like Jane Street.
Skill wise I think I'd have to start as a junior developer, which I don't mind, but perhaps having 4-5 years of working experience would disqualify me for those entry level roles?
Right now, we're looking to hire an FPGA engineer in London. Our hardware team is still small, but I expect we'll be doing more hiring as time goes on.
Seems like a nice and interesting company to work for! Except I honestly wonder ... how do you explain to your friends and family what kind of work you do, and how it makes the world a better place? (besides "making the market more efficient")
The answer to this should be placed more prominently on the website, imho.
OCaml isn't without its warts (like any language), but I don't quite think you've nailed them.
For one, the different stdlibs are in fact highly compatible. Basic types (option, result, string, int, array, float) are all the same, so code using different stdlibs works together seamlessly most of the time.
Lwt and Async are a different story, and there is a real incompatibility problem there.
The syntax extension story is pretty clear and simple: PPX rules the roost, and the tools for building PPXs are quickly getting better and more unified. Reason is an interesting variant in the ecosystem, but its existence doesn't amount to a wart in my eyes. It's an alternative syntax that you can use interoperably with the rest of the OCaml ecosystem (and Dune makes that awfully easy.)
That's not the intended implication, and Jane Street has in no way taken over the show. Our PRs are discussed vigorously, just like everyone else's, and they're definitely not always accepted!
Indeed, one of the great things about the OCaml compiler development process is that the core team is highly skeptical, and does a good job of rejecting marginal changes.
I'm not sure I agree with the "don't do it often". Having jane-script (which is our OCaml scripting system) has allowed us to greatly reduce our dependence on Bash.
That said, there are still little things we use Bash for. But our tolerance for large bash scripts has diminished greatly over the years.
Indeed, js_of_ocaml is kind of shocking in its fidelity. It can compile even highly complex libraries that do lots of runtime tricks. Async_kernel and Incremental_kernel both compiled and worked without any issues whatsoever.
We've even built some support for making incrementally rendered web-apps in OCaml, using Async and Incremental. Here's a link:
It sounds like Bucklescript is doing something quite different, which is to aim for pretty JavaScript output, while compromising and maintaining semantic consistency with OCaml. I don't fully understand the use-case, but for us, js-of-ocaml is clearly the thing we want.
We use OCaml as a general purpose tool, and it really excels in that role.