4 ms·

I guess I might have some misconceptions of OCaml. Are there other companies that use it? I ask because whenever someone says "OCaml is used in industry, for ex

I guess I might have some misconceptions of OCaml. Are there other companies that use it? I ask because whenever someone says "OCaml is used in industry, for example, Jane Street", they say it like it's just one example, but it's always Jane Street.

angio 6y ago
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 https://ocaml.org/learn/companies.html
- non-entity 6y ago
  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.
  - twic 6y ago
    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.
  - nesarkvechnep 6y ago
    Just to make it clear, OCaml is not purely functional.
    - non-entity 6y ago
      Oh sorry, not sure why I thought it was.
      - johnisgood 6y ago
        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/cryptokit.ml?ts=2#L1023 https://github.com/xavierleroy/cryptokit/blob/master/src/cry... This (this entire file) is a great example, too!
  - uHuge 6y ago
    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.
dimitrios1 6y ago
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.
kdkeyser 6y ago
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.).
johnisgood 6y ago
Frama-C, Why3, and Coq are written in OCaml. :)

angio 6y ago

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 https://ocaml.org/learn/companies.html

non-entity 6y ago
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.
- twic 6y ago
  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.
- nesarkvechnep 6y ago
  Just to make it clear, OCaml is not purely functional.
  - non-entity 6y ago
    Oh sorry, not sure why I thought it was.
    - johnisgood 6y ago
      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/cryptokit.ml?ts=2#L1023 https://github.com/xavierleroy/cryptokit/blob/master/src/cry... This (this entire file) is a great example, too!
- uHuge 6y ago
  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.

dimitrios1 6y ago

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.

kdkeyser 6y ago

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.).

johnisgood 6y ago

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