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.
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...
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:
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.
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...
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.
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.
Actually, we've funded lots of things that we don't directly use. For example, we funded the development of OPAM, which we don't use internally at all. Moreover, the funding of OCaml Labs was aimed broadly at improving the OCaml ecosystem, rather than just addressing our narrow internal needs. Our work and funding on compiler improvements like Flambda is aimed at things we want, but they're also of broad utility to the users of the language. Merlin is another example of something we've supported that is useful to us internally, but also useful more broadly.
This is of course self serving in the sense that we think the OCaml ecosystem is important to our future, and so we want to help it flourish. But it's a relatively enlightened form of self interest...
I've heard similar things from folks at Twitter, IIRC. But I do find the whole thing kind of mysterious, I have to admit. I'd love to learn that I was wrong.
Async and LWT give you lightweight concurrency mechanisms. Libraries like Async.RPC give you lightweight remote invocation, and Async_parallel gives you simple mechanisms for spinning up multiple physical processes and communicating between them.
Don't get me wrong: OTP by all accounts has richer support for this kind of stuff. I think OCaml is a better language for many purposes, but OTP is a great runtime and set of libraries whose equal is not yet found in any other language as far as I can tell.
For an HTTP server you should use Async or LWT, which are lightweight concurrency libraries. You can handle quite high levels of concurrency with either one. My impression is that people building highly parallel HTTP servers do quite well with collections of processes with a load-balancer in front, but it's not my area of expertise.
For what it's worth, the world has changed since then: Core_kernel (which is the highly portable bits of Core, which is most of it) works on Windows just fine. Indeed, WODI, which is the best windows package manager for OCaml right now, ships with it.
We use OCaml as a general purpose tool, and it really excels in that role.