I worked at a startup (Amplidata) where we build a distributed storage system in OCaml. It got acquired by Western Digital, which later sold it to Quantum. Afaik, there is still development going on using OCaml.

Couple of things I took away from the experience:

- After an initial ramp-up, most of the developers liked or even loved the language. Downside was the limited tooling/libraries (2010-2015, seems better now).

- Quality of the resulting product was quite high: bug rate was fairly low, especially once experience with the language increased. Turns out sum types, gadts and the module system (functors) are very powerful to express invariants and design composable logic.

- OCaml was successfully picked up by team members without a formal computer science background, or even without a lot of programming experience. Not that it turns everybody into a great programmer, but it seemed to coerce new hires into delivering a working feature, without a huge risk of breaking a lot of other code.

- It is still possible to write crappy / unmaintainable code. But in OCaml it is often as easy (or even easier) to write good code.

- If something did turn out to be broken, it was painful. Debugger support (GDB) was initially non-existent. Under heavy load, we triggered a couple of bugs in libraries, which was quite painful to fix. On the other hand, we also triggered bugs in malloc and in the Linux kernel, which were as painful, so it might have had more to do with the high-load scenario, than with OCaml.

- For really low level stuff, or very high-performance cases, we did need to use the escape hatch to call C code. Interfacing Ocaml with C was not the most pleasant (was before ctypes library). Debugging bugs at that boundary was extremely unpleasant. One trigger for this was the fact that multicore OCaml never materialized, which also damaged the "political position" of OCaml within the company.

- Management (especially after the acquisition) was at best indifferent, and at worst hostile towards it. OCaml was perceived as being difficult to hire for (or outsource). Using more "standard" languages like Java, C++, Python was seen as the safer bet. They tried and often failed (C++ turns out to be damn complex, and maintaining a large Python codebase turned into whack-a-mole, but for bugs.).

The OCaml website lists some companies it [0], I think there are a bunch of new blockchain startups that are also using OCaml but are not on that page.

[0] https://ocaml.org/learn/companies.html

Is there something about purely functional languages that make them attractive to blockchain applications? I remember a post on here a little while ago complaining about Haskell adoption in industry was being mostly led by cryptocurrencies.

One person might say that the common factor is not being frightened of doing something challenging and unconventional that allows you to achieve extraordinary things.

Another might say it was a weakness for snake oil.

You have high-stake operations in relatively small code base, so you better pick a language and tools compatible with formal verification or even supporting it natively.

Just to make it clear, OCaml is not purely functional.

Oh sorry, not sure why I thought it was.

Yeah, it most likely is not. I mix imperative, OOP, and functional all the time. Parts of my codebase that has to do with algorithms are written using imperative style, the "public API" is OOP (class, object, methods) which makes the use of my library a breeze, and the rest is functional.

To give you an example of how you would use some crypto-related library that implemented its API (?) in OOP:

  let x = new Foo.bar in
  x#absorb a;
  x#squeeze b;
  x#reset

Or take a look at: https://github.com/xavierleroy/cryptokit/blob/master/src/cry...

This (this entire file) is a great example, too!

Facebook is big into it via tooling and compilers. It's also big on the Messanger team ala Reason.

Ahrefs is another one I know of.

And hopefully (maybe?) my company soon.

Frama-C, Why3, and Coq are written in OCaml. :)