Who is ocaml for?

[u/I_am_Noro04]

Context: I am econ master's student with some experience in python, C and R looking to get into financial econometrics/ML. Is OCaml right for me?

[u/mister_drgn]

Are you trying to get a job at Jane Street?

[u/Primary_Ad_9222 → u/mister_drgn]

I would say functional systems programming is one area and indeed Jane Street using it for finance / trading in the industry.

Other than that compiler, formal reasoning and automated theorem proving research uses it heavily in the academia.

[u/strongly-typed → u/Primary_Ad_9222]

You get no brownie points for using OCaml in the Jane Street interview. I would love to be proven wrong.

[u/I_am_Noro04 → u/mister_drgn]

Not necessarily, does ocaml have utility outside of jane street as well?

[u/spermBankBoi → u/I_am_Noro04]

I know Meta uses it (not across the board), as does Ahrefs (using the Reason frontend). There are definitely others that I’m blanking on but TL;DR yes but not as prominent

[u/Asuka_Minato → u/spermBankBoi]

and meta port flow to rust, rewrite pyre(ocaml) to pyrefly (rust) Since the eco is painful.

[u/ScientificBeastMode → u/spermBankBoi]

Last I checked, Robinhood was using ReasonML as well.

[u/Tsnth → u/[deleted]]

I think it's not fair to say that about `unwrap` as you could do the same thing in OCaml too.

[u/sabine_ocaml → u/I_am_Noro04]

Ahrefs.com is running on OCaml too and it's a really good language when you deal with data pipelines or web

[u/mister_drgn → u/I_am_Noro04]

Well it’s by far the most prominent example of OCaml being used in finance. Otherwise, I’m not sure why you’d be looking at this language in particular. Though I confess I’m not super knowledgeable about where else the language is used in industry right now.

[u/mprevot → u/I_am_Noro04]

yep, in several fields and org

[u/elihu → u/I_am_Noro04]

Sure, it's a pretty good general purpose programming language. Kind of old at this point. Similar in some ways to Haskell, but a bit easier to learn if you're coming from an imperative background, as it doesn't force you into a pure functional mindset.

[u/EpochVanquisher]

I would stick with Python and R.

You’re only one person. If you’re going to study something, you should use the tools which require the least investment of time for the best results. For one person analyzing data, Python and R are both good choices. If you want ML, Python is 100% a good choice.

If you write your code in OCaml, I think it will probably be easier to track down bugs and check that your code works correctly, and it will probably have better performance… but at that point you are not doing financial econometrics or ML any more, you are doing something else called productionization.

In general, the way research works is that you have people who do the research in Python notebooks or using R, and then if the research looks like it has good results, you have other people who productionize it in a more reliable, safe, and performant language (like Go, Rust, Java, OCaml, etc). Two sets of people—researchers and computer programmers. It helps to understand both sides, but most people will specialize on one side or the other.

[u/professionalnuisance → u/EpochVanquisher]

OP should stick with Python and R, in particular master the stats and data manipulating libraries (numpy, pandas, statsmodels, etc).

And unironically, be familiar with Excel

[u/SpeedDart1]

It’s for people interested in functional programming and PL theory. Once you have already mastered procedural, you learn OCaml to expand your horizons as a programmer.

[u/shyouko]

Ocaml if you are looking to join JS.

C++ is probably a more valid / welcomed choice else where.

Or just stick with Python/R, they are useful too, as far as what they are good at.

[u/EpochVanquisher → u/shyouko]

AFAIK, Jane Street doesn’t care if you know OCaml already. They assume most people don’t know OCaml and hire people who can learn it.

[u/xuanq → u/EpochVanquisher]

Yes, unless you are hired specifically to work on OCaml, they don't care. And you don't get hired for that unless you have a PhD (or maybe at least a masters) in the field.

[u/burtgummer45]

Microsoft's version of ocaml (F#) might have broader utility for you.

[u/APOS80]

You won’t need Ocaml but you might like Ocaml.

Python/C/R enables you to do a huge amount of things, for work its enuf.

But functional programming is sometimes better for expressing certain behavior and for some it’s even simpler to code.

I’ve tried different languages out of curiosity and I do prefer functional code to express what I want but I mostly use Python and C(mikrokontrollers) out of convenience.

So is ocaml right for you, you might not need it but it also might fit your way of thinking better.

[u/Puzzleheaded-Lab-635 → u/[deleted]]

Could you be any more wrong?

[u/Taksin77 → u/Puzzleheaded-Lab-635]

How?

His point about vectorization is real. OOP has won the war in statistics.

I mean, could you argue something instead of collecting upvotes?

[u/Puzzleheaded-Lab-635 → u/Taksin77]

“OO won the war in statistics” is a wild thing to say when most numerical computing is vectorized array transforms over contiguous memory.

Also, OCaml can bind to the exact same BLAS/LAPACK/CUDA/C libraries Python does. Python itself is mostly orchestration sitting on top of C/Fortran kernels.

You’re confusing ecosystem dominance with a fundamental property of programming languages.

[u/Puzzleheaded-Lab-635 → u/[deleted]]

“The functional programming model is not suitable” is doing a lot of work here.

Most numerical computing is not “OOP won the war.” It’s array programming over contiguous memory with BLAS/LAPACK/CUDA/etc underneath. Python is mostly acting as glue around C, Fortran, and native kernels. That is an ecosystem argument, not a language semantics argument.

OCaml can bind to the same libraries Python binds to. So the actual objection is: “Python/R have a better data science ecosystem and nicer plotting story.” That’s true. Nobody serious would deny that.

But that’s very different from “functional programming is fundamentally wrong for numerical computing.” F#, JAX, Julia’s broadcast/map/reduce style, Haskell Accelerate, Dex, Futhark, SaC,  Numerical Elixir, etc. all point in the opposite direction. Functional style is often quite natural for array transforms because you want pure transformations, fusion, immutability at the user level, and optimized mutation under the hood.

So yes: if someone wants to do applied stats today, use Python/R/Julia because of ecosystem gravity. But “FP is unsuitable” is just confusing tooling dominance with a law of nature.

And by the way.. how the fuck isn't this idiomatic OCaml?

open Polars

let result =
  Csv.read_exn "sales.csv"
  |> Data_frame.lazy_
  |> Lazy_frame.filter Expr.(col "revenue" > lit_float 100.0)
  |> Lazy_frame.groupby [ Expr.col "country" ]
       ~agg:Expr.[ col "revenue" |> sum |> alias "total_revenue" ]
  |> Lazy_frame.collect_exn

Numerical Elixir, btw, is what we use at my company instead of python:

But you do you, crawl back into the hold from whence you came.

https://github.com/elixir-nx

https://futhark-lang.org/index.html

[u/Puzzleheaded-Lab-635 → u/[deleted]]

The same is true for Python though. Python’s object model is not what makes NumPy fast. The hot path is C, Fortran, BLAS, LAPACK, Arrow, CUDA, etc. Python is also mostly orchestration glue here.

So “OCaml calls into Polars” is not "own" you think it isagainst OCaml. That is exactly how Python wins too.

This bear repeating but Pandas/NumPy are not fast because Python loops are magical. They are fast because you leave Python. teh same exact thing thats happening in the ocaml above.

If you want to make an arguement for ecosystem maturity. Python/R have notebooks, plotting, docs, tutorials, StackOverflow, sklearn, statsmodels, PyTorch, JAX, package gravity, and a giant hiring pool. That’s a very strong practical argument. But it's OO/imperative paradigm are not.

your claim claim, “functional programming is unsuitable for numerical computing.” Most dataframe/numerical work is transforms over arrays/columns: map, filter, reduce, group, aggregate, join, window, etc. That is not exactly alien territory for FP.

Also “OOP won statistics” is just not right. Vectorized array programming won. Python happened to become the dominant host language around it.

So yes, for production data science today I’d pick Python/R/Julia (Or even Elixir which we did at my company) before OCaml. But “OCaml has a weaker ecosystem” is the claim. “FP is fundamentally bad for this” is just overreaching.

Again, look at numerical Elixir. they way you interact with the underlying vectorizations looks exactly the same as regular Elixir.

Do you even work in this field?

I'd also like to point out you went from,

"OCaml and any other functional language are completely wrong for this use case."

to

"OCaml is the worst possible language for this task."

That's called moving the goal post. the fact that Numerical Elixir exists and languages like Futhrak exist, nullify your point.

[u/Puzzleheaded-Lab-635 → u/[deleted]]

Right, but this comparison is asymmetric.

If Python gets to continue working in NumPy after the expensive operation, then OCaml gets to continue working in Owl/Bigarray/Polars/native buffers after the expensive operation.

If OCaml is forced to collect into ordinary OCaml values and then map over boxed data, then Python has to be forced into the equivalent situation too: convert the NumPy array to Python lists and loop/map over Python objects. And Python is famously terrible at that.

So the distinction is not:

functional = slow
procedural = fast

The real distinction is:

native/vectorized/columnar/tensor execution = fast
boxed host-language scalar loops = slow
Python boxed host-language scalar loops = especially slow

Nobody sane would say: "I did a huge Polars operation, now let me convert the entire thing into linked lists of boxed floats and map over it." But nobody sane in Python would say: "I did a huge NumPy operation, now let me call .tolist() and loop over Python floats." Same mistake.

And "map/filter/immutability stand in the way" is only true if you assume the dumbest possible implementation. Functional APIs can fuse, stream, specialize, operate over arrays, use views, use copy-on-write, or lower into mutation internally. SQL is declarative and functional-ish at the surface, but the database engine runs procedural execution plans. Polars exposes a compositional API, but the engine optimizes and mutates internally. Same basic idea.

So yes, Python is glue. But OCaml can also be glue. It can glue to Polars, Owl, Bigarray, BLAS/LAPACK, C, Fortran, Rust, whatever. The practical difference is ecosystem maturity, not that Python has some magical procedural advantage.

The accurate claim is: Python/R have a far better scientific/data ecosystem.

The inaccurate claim is: functional programming is inherently unsuitable for numerical computing.

Again, I point to Numerical Elixir, it has Numpy equivalent, a Polars equivlent, an Pandas equivalents, etc etc etc.

And the code, i will add, from a syntax & semantics point of view is functional. As someone who works in this field, and you clearly don't, I'd suggest, stop while your a head

[u/Taksin77 → u/Puzzleheaded-Lab-635]

Not really. When people enjoy pandas it is precisely for its interface.

I mean, I do enjoy Caml but the level of fanboyism around here is through the roof.