Why use OCaml over Python

Learning
1

Hi Folks,

A bit of background. I heard about OCaml long ago, but I’ve never looked at it properly. Then Facebook released the Flow for javascript and ReasonML. It was then I realised the power of the OCaml’s type system. Over the years, I’ve done some Clojure and Elixir, so I am familiar enough with functional programming, and I like it a lot.

But I’ve been a software developer professionally for nearly 15 years. Though I’ve flirted with other languages, the primary language I have been using is Python. And it’s getting more and more popular. I am working on a new web app backend. It’s a new project I would like to get it off the ground soon, and it’s AI related. As we all know, Python is well-positioned in this space.

Yet, I have been learning OCaml in the last few days :slight_smile: I really want to use OCaml as API backend for this product. But at the same time, it’s such a paradigm shift since I have been mainly using Python and Python as a supported ecosystem in the LLM space.

So I want to hear the folks who used OCaml in production to know the pros and cons of using OCaml in prod. And hope you can convince me to use OCaml? I know, as any seasonal dev would say, use the tools that suit the job and use the tools you know the best. But my heart keeps telling me to learn OCaml :smile:

9 Likes
2

Hi tianyi,

I am in a situation not unlike yours (18+ years of python but an eye on OCaml / Haskell for as long) and started 3+ years ago using elm on the front end. It is certainly delightful to have such a nice type system and a compiler that flags everything wrong very quickly. Now I have been watching the OCaml space for some time, with the same idea as yours (why not use it instead of Python for the backend side ?), and though I still want to get there at some point I have come to realize how radical a change it will be. Having a 6 months break from normal work duties would certainly help !

3

Hi @zogzog,

Glad to hear that I am not the only one. It’s very strange that OCaml has this strong pull for people like us. Maybe not just OCaml, Elm might be in the same category. I think it’s the desire to use a Pratical, Strong typed Functional programming language which also has a fast compiler :slight_smile:

1 Like
4

I recently got back into (circuit)python after a long spell with OCaml.

I immediately cried out, “Why doesn’t it work?” Because with OCaml, I’ve become accustomed to getting an error as soon as the code is compiled.

OCaml is more rigorous but heavier to set up. On the other hand, the benefits are felt in the long term. When a project starts to become too complex to know every line of code by heart, I’ll have more confidence in OCaml, which allows me to be sure that every part connects correctly with the rest of the code.

Make a list of the dependencies/libraries required for your project before you start (in some areas, OCaml isn’t appropriate because the ecosystem isn’t as well developed).

6 Likes
5

Thanks @Chimrod

This makes total sense. Long term maintainablity is defietnetly a pro for OCaml I think.
On the ecosystem part, you need people to develop it.
If everyone comes into OCaml, and look at the ecosystem, and say, hey there’s no such library for my project and they leave. Then the eco system will never grow, right? Catch 22 situation really.

6

Hi, here is another experience report from someone who uses ReScript (which is based on OCaml): Just pitched using rescript at my company and was shot down - #10 by moondaddi - react - ReScript Forum

I found there are a couple of interesting points in there about why to invest in this kind of language.

7

Speed. Due to the lack of native compilation, Python will never reach the same performance (PyPy isn’t really practical). Moreover, multicore OCaml and libraries could help drive this gap even further depending on the task.

8

Raw speed, for sure. But for a back-end API applications, sometimes raw speed is not the most important thing. It can be mitigated by using caching, a queue system for heavy computing etc. Even using OCaml, one should implenmeting these strategies also.

Instead of raw performance(though it is a plus), I am more thinking if OCaml can provide more developer productivity in the long run. Can anyone confirm some hypotheses I have?

With the strong type system:

  1. It can help the team collaborate better.
  2. It can help make refactoring easier and less error-prone.
  3. Write fewer tests comparing dynamic langs.

With the fast compiler:

  1. Faster feedback loop.
  2. Do tests run faster too? One of the biggest pain I have with python is when a project grows, the testes can be very slow.

The last one is hiring, and it’s a pro and a con.

Con: fewer people know OCaml

Pro: It can attract people who want to use or learn OCaml. This type of programmer is not just looking for a job. And if they like the language and the ecosystem, they will produce better work, too.

5 Likes
9

You should likely write as much tests[1].

But you can skip the stupid tests that one needs to write in a dynamic language to be able to refactor representations with peace of mind. That, the static type system will catch for you and tell you exactly where you need to make your changes.

  1. Personally guilty of not writing enough of them. ↩︎

3 Likes
10

A few years ago we switched from Python to Ocaml as our main programming language. At this point we had used Python for about 20 years.

The main improvements were in runtime stability and code organization. The single most important reason for the stability improvements is OCaml’s explicit handling of None values. OCaml’s module system turned out to be a vast improvement over OOP for us.

We use a quite basic subset of OCaml, no fancy features like GADTs, hardly any functors, no OOP.

We are very happy with the switch and didn’t look back.

10 Likes
11

About a decade ago Thomas Leonard (now project lead of the Multicore effect system Eio) did a large real-world OSS project migration from Python to OCaml and wrote about it: Python to OCaml: retrospective - Thomas Leonard's blog

9 Likes
12

If you’re building with LLM products that have APIs and not necessarily training models and whatnot yourself, you’ll likely be fine.

Don’t be like me and try to get eio to work with your web server, your postgres library, and whatever else hahaha. Stick with lwt or async and you’ll generally have all the available tools to build web apps (if that’s what you’re building).

2 Likes
13

Thanks to pioneers like you it’ll be easier for the next person though.

1 Like
14

That’s great to hear!

1 Like
15

Yeah, that’s exactly it. My plan now is to build the main API layer using OCaml, if the certain 3rd party serviece I use does not support it, I will just switch to Python and let have some backend rpc calls should be fine.

And thanks for the advice.

16

This 100%. I think we need people in the community to do things the hard way. So people like me can learn from it, and I hope I will someday help newcomers the same way!

17

This tweet from a very exeperinced Python developer is timely for this discusssion. And OCaml will be easier in the long run.

18

because I like functional programming, OCaml is the goat.

1 Like
19

Consider Python is a swiss army knife.
Living in Japan, I can tell you, OCaml is a pretty sharp katana.

Now, consider your problem: how big is it?

Do you want to try cutting your problem using a swiss army knife, or a katana?

5 Likes
21

I confirm the hypotheses that you have.

Mr. Chad Fowler wrote about the hiring issue that you mentioned in his books.

@book{Fowler2010,
	Address = {Raleigh, {NC}},
	Author = {Chad Fowler},
	Edition = {Second},
	Publisher = {The Pragmatic Programmers},
	Series = {Pragmatic Bookshelf: Pragmatic Life},
	Title = {The Passionate Programmer: Creating a Remarkable Career in Software Development},
	Year = {2010}}

Chapter 2, pages 27-30, and Chapter 5, pages 37-40, describe this.

The first edition of the book was known as, “My Job Went to India: And All I Got Was This Lousy Book.”

The self-motivated software developer who cares about career growth will engage in lifelong learning and professional development, and avoids using systemic/structural and institutional inequity/bias (e.g., racism and anti-immigrant bias/discrimination) to get jobs and promotions.

So, using OCaml primarily for your code base can filter out the not so motivated software developers.

You can borrow/copy the (former) hiring practices of Galois, which develops most of their work in Haskell. They shared resources, and links to open access/content books (e.g., books published under the Creative Commons license), to help applicants for internships and jobs learn more about Haskell.

Another critical issue that many have not shared is how modern C++ (e.g., C++23, C++20, C++17), modern Java (recent versions), modern Python (3.7 and beyond), and modern JavaScript support functional programming features for opertions like map-filter-reduce.

So, if you look at a candidate’s code base, you can figure out if the candidate has experimented with such features in a “programming sandbox” (to try features of a programming language or library/framework/package) or used them extensively in the code base for most projects.

Also, wage remuneration is also the key factor. If you pay software developers and digital integrated circuit (I.C.) designers a lot of money, they will come work for you. Jane Street Capital pays FPGA interns about US$125/hour as a base salary. So, if undergraduate frosh/sophomores have taken an introductory course on digital/logic circuits, and experimented with hardware construction languages (H.C.L.s) or modern hardware description languages (H.D.L.s) for their laboratory assignments, they would be able to apply for the internship.

If they have taken an introductory digital I.C. design course as an undergraduate sophomore/junior, this would make them stand out.

The caveat is to use software development practices, or computational thinking, to improve digital I.C. design. Taking a course on "data structures and algorithms” helps, but using version/revision control (or software configuration management), automated regression testing (or automated regression verification in the context of digital I.C. design), software architecture modeling (UML/SysML can model digital I.C.s), DevOps (used in VLSI/hardware DevOps), working in UNIX-like environments (via OS-level virtual containerization, such as Docker or Kubernetes and their variants like KubeFlow for machine learning - modern AI-powered electronic design automation software use these anyway), and documentation to improve communication about different aspects of the I.C. design project helps a lot.

I mention this since Jane Street Capital created their own H.C.L., Hardcaml, which is based on OCaml. They love people who have experimented with different H.C.L.s and modern H.D.L.s, such as Chisel HDL (based on Scala), Clash (based on Haskell), and PyMTL/PyRTL/PyGears/PyLog (based on Python).

In the interest of broadening participation, I pay attention to how marginalized and less privileged people work on something in their free time with appropriate timestamps. E.g., if they developed something in 2 hours since they are working 20+ hours per week while maintaining a 4.0 G.P.A. at a decent/competitive research university, I will assess that accordingly. More privileged people should be able to find time to put in more work, and use better tools/frameworks/libraries/platforms/paradigms. That way, you can have diverse teams who can look at problems or issues from another perspective, and avoid common mode/cause failure.