Hacker News Reader

Comment by TallGuyShort | Hacker News Reader

I've never encountered a real OCaml project or anyone who uses it in my career (same is true for Haskell). I have assumed these languages are a hobby for CS academics and get used for pet projects by their devotees. Not that that's bad - they're interesting and the ideas are cool. I would just be afraid of locking myself into an isolated ecosystem that it's hard to hire experienced people for. Is anyone on HN actually using these languages for scientific computing, or other large production projects? Curious to know what the pros / cons are in practice and how common that is.

View on HN

I use OCaml at work. We work with the Binary Analysis Platform https://github.com/BinaryAnalysisPlatform/bap which is a pretty essential part of what we do. In general, OCaml seems somewhat popular in the area of compilers and program analysis. Facebook Infer is written in OCaml for example https://fbinfer.com/. This may be as you said because of these areas sometimes more academic flavor. There are companies out there using OCaml for all sorts of things, although of course it is a small fraction of those using python or C++.

Haskell and OCaml are definitely not just hobbies. I've used Haskell full-time for the last five years of my career.

The company I work for uses Haskell for a network packet parsing engine, web api servers, CLI executables, build infrastructure (alongside Nix and NixOS), an interpreter for a custom programming language, a gateway/proxy service for AWS services, etc.

I've talked to at least one persons who works on production Haskell applications, and Jane Street, a company that was discussed on HN just yesterday makes heavy use of OCaml, but yeah they're pretty rare and I suppose the people working with them are just lucky. I've heard particularly about the Haskell market that if you want a chance of competing for the few jobs available you have to be among the top-haskellers, but I'm not sure.

Jane Street being the only company that anyone ever mentions when discussing OCaml is even worse in my opinion. It means the ecosystem is going to be heavily driven by their needs, not to mention that banks tend to have idiosyncratic development cultures.

It is not the only one though. There are Ahrefs, Tarides, Tezos, Citrix (XenServer and a part of Xen are in OCaml), Inria, Facebook (for compilers, typecheckers and ReasonML), Bloomberg (was Bucklescript/ReScript, now at facebook though I believe).

There are also some academic projects with industrial uses. Directly to mind come Coq, Frama-C, Mirage and the Zélus compiler.

EDIT: added Inria and Frama-C

JaneStreet is not the only user of OCaml.

Both INRIA and the CEA uses OCaml heavily (Coq, CompCert, Frama-C). Cambridge uses it for MirageOS, Facebook to write software analysers and now web applications (the web version of Facebook Messenger), Citrix in XenServer. Bloomberg developed a compiler from OCaml to Javascript.

Facebook also uses it and will probably have more of an emphasis on it now with their ReasonML project

Jane Street only gets mentioned so often because it is one of the highest paying and selective companies in the world. They are not in control of the ecosystem. And they have nothing to do with banks.

Docker for Mac uses OCaml for a critical virtualization layer. So does every cloud compute provider that runs on Xen virtualization: https://twitter.com/yawaramin/status/1284976603454492674

Jane Street has 900 employees, I'm guessing 600 in US and maybe 200 devs at most.

I'm not very familiar with the scientific landscape of Haskell or OCaml, but if you would allow an educated guess...

Languages like R, Python, Matlab, and Mathematica have a LOT of built-in capability in this area to do symbolic and numerical methods and data analysis kind of stuff (large sparse matrices... etc). You can do a ton in the high level language without ever dropping down to C or Fortran. So a scientist can just do their job without having to worry about how the plumbing works as others (open source community for Python and R) or vendors (Matlab and Mathematica) take care of that, which is a huge win.

Back when I thought about doing scientific work in Ada, Rust, OCaml, and Haskell, I was dissapointed to see that either there were many libraries missing that I would need, or the existing ones were incomplete. The solution is usually just to FFI to Python or C, but at that point, I think you lose a lot of the magic of sticking to 1 high level language. Just my 2 cents. If you're comfortable in doing all the scientific bits in C and just calling from OCaml, then you should be fine. On the data analysis side though, R or Python + Pandas just have sooo much inertia.

I'll add that this book's table of contents seems to have some really neat topics, but a lot are just a single page long and I still think a lot of areas (Ex: linear algebra) are going to be a lot less complete than what Python has to offer. With that being said, the scientific scene I'm seeing in this book is much farther along than I would've guessed, so that is a good sign.

I am part of Owl contributors/maintainers.

You are right that the ecosystem is small, and will likely be always behind Python, R and Julia. But considering how small the community around numerical methods in OCaml is, I think the work that went into owl and this book is incredible and may help raising awareness and growing the userbase.

I think one of our current limitations is the lack of a high quality, full-featured plotting library. There are some which are used for publication level plots, but they are nowhere near the experience of plotly, matplotlib, ggplot2 or julia's plots.

In any case, the community seems to be slowly growing already, so there is some hope. I think the best would be if we can start integrating it with SciML and similar projects.

Thanks for the hard work! I always appreciate any contributors even if I have only used OCaml a few times.

I think y'all are definitely raising some awareness and I agree the lack of a plotting library is a major hurdle. You can always call out to GNUPlot from the terminal, but most folks probably don't want to do that.

Thanks for the kindness!

There is actually a GNUPlot backend for Owl. Works very well, but is a bit lowlevel: https://github.com/hennequin-lab/gp

Similarly, I use https://github.com/mseri/ocaml-gr but it is a safe lowlevel binding. I hope one day to have the time to wrap it into an interface similar to Julia's one.

Not a problem at all. Thanks for chatting and sending the links. I wish you the best on this project. Maybe it will help get OCaml some additional/well-deserved attention and love. I'll keep my eye on the project too. Is anyone working on data frames?

I am only aware of the discussion at https://discuss.ocaml.org/t/ocaml-vega-lite-and-ocaml-datafr... and at this chapter of the book: https://ocaml.xyz/book/dataframe.html

I don’t think there is work going on on that side of owl at the moment if this is what you are asking.

> You are right that the ecosystem is small, and will likely be always behind Python, R and Julia.

But you should be able to call those languages from OCaml. For instance, RInside

https://cran.r-project.org/web/packages/RInside/index.html

lets you call R from any language with a C FFI. A very simple solution (even if not quite as convenient as a full OCaml solution) that lets someone write OCaml if that's their preferred language. I helped add that functionality to RInside and I've been doing that for years so I can use D for my research.

Indeed! There are already OCaml bindings for many R and python packages in the opam repository (opam is the package manager for ocaml), as well as C and fortran libraries. Similarly there are now a few packages to interact with rust. I think, right now, only a library to interact with julia is missing.

I said it earlier, but if I have to call R from another language, in most cases I'd rather just use R by itself.

Of course there are reasons why you might integrate the two. Perhaps you have an R expert doing the statistics work and the back end developer gluing everything together. That's fine, but at some point the system becomes pretty confusing and is a giant leaky abstraction.

We've written a bunch of virt tools in OCaml, used by hundreds of customers. eg: https://github.com/libguestfs/virt-v2v

OCaml is the strongly-typed functional language that sees most serious use.

It's harder to do generic polymorphism in OCaml since the language has nothing like C++'s parametric templates or Haskell's type classes. It does have a very nice module system that has the required flexibility, but compared to these languages, I think it is clunky for the kind of genericity seen in scientific computing.

I think Julia has shown us that strong typing is not really needed for scientific computing.

> It's harder to do generic polymorphism in OCaml since the language has nothing like C++'s parametric templates or Haskell's type classes. It does have a very nice module system that has the required flexibility, but compared to these languages, I think it is clunky for the kind of genericity seen in scientific computing.

Are parametrized modules really clunkier than parametric templates ?

At least for beginners, they absolutely are. I have found undergrads generally get the idea behind something like HashMap<Integer, String> but getting them to reason about OCaml modules takes quite a bit of effort.

(int, string) Map.t doesn't seem to be too many steps away from your example. When I was learning OCaml, I found that much of the module and module type system can just be seen as a more beefed up version of interfaces in OOP languages, so it didn't take long to see its benefits.

> I think Julia has shown us that strong typing is not really needed for scientific computing.

I think you meant static typing, in opposition to dynamic. Julia is strongly typed like OCaml.

Julia has dynamic typing, not static. You can specify types, but they don't really do anything except help with performance.

A far cry from OCaml's great type inference and compile time static checking.

The grandparent meant that OCaml is static while Julia is dynamic, and both are strongly typed.

>You can specify types, but they don't really do anything except help with performance.

For Julia it's the exact opposite though, types don't help with performance since the compiler infers them anyway regardless of declaring them or not (you only really should to specify in very particular cases where inference is not possible to avoid the compiler being too conservative, and if you overspecify types you might even end up with a slower program). You declare them for their main purpose of controlling dispatch.

Julia's type system is a core aspect of it's paradigm (multiple dispatch [1]), which is the key element in both it's performance and polymorphism. It's different from a gradual typed language in which the language can exist without the types at compilation time, but those can be optionally added to enhance safety or performance, Julia cannot be compiled without knowing the types, which will happen regardless of declaration.

[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

That said, types in Julia are not used for compile time static checking, which is a compromise that for many tasks it's not worth it. Ocaml ML and Julia ML can coexist well exactly because they have vastly different compromises, with Julia focused on interactivity/fast prototyping and Ocaml in safety (like Lisp x Haskell, but with somewhat more pragmatic languages).

An example of OCaml use in scientific computing is to derive the framework for the FFTW library, which is rather important. (No, the library isn't written in OCaml, as I've seen claimed.)

Bad statistics sorry.

Reply on news.ycombinator.com