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 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
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 !
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
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).
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.
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.
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:
It can help the team collaborate better.
It can help make refactoring easier and less error-prone.
Write fewer tests comparing dynamic langs.
With the fast compiler:
Faster feedback loop.
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.
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.
Personally guilty of not writing enough of them. ↩︎
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.
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).
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.