As someone interested in learning OCaml, this felt like a pretty inaccessible introduction.
Having seen "A tour of Elm,"[0] I really prefer that style. The left-hand side (what English readers read first) is an explanation of the concept, then the right side is the code, and the explanation gives you enough details to complete the code.
This introduction doesn't really explain anything, as I guess it assumes you've learned OCaml elsewhere and are just here to practice.
I tried the first exercise, and it felt more like a math problem than an exercise to teach a programming concept:
>Suppose that a variable x exists and is an integer.
>Define a variable x_power_8 that uses three multiplications to calculate x to the power of 8. The only function you are allowed to call is the (*) operator.
>Hint: use auxiliary variables.
So, at first I thought I was supposed to just call multiply eight times, and then I realized that they said you can only call multiply three times. So, you're supposed to do let a = x * x; let b = a * a; let x_power_8 = b * b. But that feels really contrived to me and not like anything I'd write in a real application, even a toy one. If the idea is teaching variables, why not just ask me to declare a variable that represents x plus 1?
Whatever the purpose of that site is, “Learn OCaml” isn't it. That's a bad title, there is nothing in there that helps a beginner learn OCaml. It's more like a series of tasks where you already have to know OCaml to various degrees.
> This introduction doesn't really explain anything, as I guess it assumes you've learned OCaml elsewhere and are just here to practice.
Indeed the link is a not an introduction to OCaml but a demo instance of Learn-ocaml which is framework for building online exercise websites to complement (online or physical) lectures. This is why the instance is hosted on the OCaml Software Foundation website rather than ocaml.org: the demo is not targeted to learners but to teachers.
In ocaml you would rather do something like this: let x_power_8 = (let a = x*x in let b = a*a in b*b);
a, b variables are just used for computing x_power_8, you don't need them outside of this scope. I think the point of the exercise is to use variable binding, though I agree the website doesn't explain much
"that feels really contrived to me and not like anything I'd write in a real application"
If that bothers you, you shouldn't be learning ocaml. Look at the latest stack overflow developer surveys. A vast majority of developers and real applications never touch ocaml.
> If that bothers you, you shouldn't be learning ocaml.
That's not what OCaml is like, at all. You clearly hate it, for whatever reason. Fine, have it your way. But popularity contests on SO are not an argument and they explain nothing.
At Rust Chipotle, they have strict rules about the ingredients for your burrito. "White rice with medium salsa, sir? Absolutely not!". You see, medium salsa only goes with brown rice, and you also need to have beans or nothing works. Under no circumstances will they allow you to construct the burrito you think you want, no matter how much you think you want it.
Meanwhile, at OCaml Chipotle you can have whatever you like, and it always turns out awesome. But once a month you go for lunch and they'll refuse to make you a bowl, refuse to tell you why, and refuse to let you leave. And when you try to get help from a passerby after being trapped in the store, you realize there's nobody nearby who you can ask.
But arguably F# (whose original name was OCaml.NET) is underrated. It improves on OCaml in a number of areas (better pattern matching, computation expressions, namespace support) but more importantly, F# solves OCaml’s biggest problems: lack of decent libraries and subpar tooling.
With F# you get instant access to thousands of high quality NuGet packages which includes everything from fast web servers to highly performant json deserialisation, and you can use some of the best IDEs, tooling and debugger around (JetBrains Rider is outstanding IMO).
F# suffers from the Microsoft association unfortunately, even though Microsoft barely cares about it and provides minimal support for it, most good things about F# are developed and maintained by the community. But the perception exists, and many think it’s still Windows only
I’ve recently been doing a lot of F# development, I do my work on a Mac, using Rider and OCI dev containers, and the code is deployed on Kubernetes, and honestly I don’t remember the last time I enjoyed a programming language and development tooling so much.
My dayjob involves a lot of Java, but the problem I'm working on seems to be a really good fit for a functional language.
I've played around with Erlang, Elixir, Clojure and F#. The problem is that I'm always worried about getting stuck somewhere along the process and then end up regretting the decision to not use something more mainstream.
Generally you won't get stuck with F#, unless you would of got stuck with C# also. The escape hatch is there, with its pros/cons. The pro is mentioned - the con being that this is where F# gets im-pure and someone with experience would immediately have patterns/team standards to deal with the boundary/usage. C# libraries generally don't have this problem (e.g. Collections, Connection Libs/SDK's, etc) since you invoke them like any other function/object - C# frameworks which invoke your code (e.g. ASP NET Core) you typically need standard code patterns to allow most of your F# code to remain pure/simple.
In general though I prefer the .NET runtime than the JVM in its current state - you can go a little bit lower level when required in hot code without going unsafe (value types, spans, etc).
I highly recommend this resource- OCaml Programming: Correct + Efficient + Beautiful [0]. It is very friendly, fund, and informative. It is one of the proverbial 'mind expanding' stuff.
I like OCaml a lot - but I think I like F# a little more. They're very similar, since F# as essentially Ocaml running on the .NET VM.
I know some people dislike the fact that F# lacks OCaml's functors, but I can see why they weren't included. Due the the way F# integrates .NET classes/objects, I can accomplish more or less the same thing that way. In some ways I prefer it - a class/type full of static methods has the same call syntax as a module full of functions, but gives me the option of overloading the method so it'll dispatch based on argument types. Having everything that's iterable unified under IEnumerable/Seq is nice, too.
Having said all that, I still enjoy OCaml a ton. One thing I wish I could have is F#'s updated lightweight syntax brought over to OCaml. I think ReasonML is great, but after using it for a while I realized that what I really want isn't OCaml that looks more like JavaScript. What I want is OCaml that looks like OCaml, but a little cleaner. F# gives me that, plus, via Fable, compilation to JS, TypeScript, Python, and Rust. And via the improved native AOT compilation in .NET 9, I can build fast and reasonably small single-file executables.
Despite all that, I still try to dive in OCaml whenever it's a decent fit for a problem for the problem I'm trying to solve. Even if it's a little quirky sometimes, it's fun.
IMO, a language without proper modules, GADTs, or (now) an effect system, does not seem to me like it could plausibly be described as "essentially OCaml". Your point about having ad hoc polymorphism (outside of an object system) is another good point about why F# really is not OCaml on .NET.
Not to mention the difference of being trapped in (or having the luxury of, as you prefer) .NET vs. compiling to native binaries.
Loved using OCaml for a compiler course at uni when I was a student. But I've always felt that the tooling side is pretty rough, especially on Windows. Opam recently added Windows support, but it involves installing MinGW, and when following the official docs https://ocaml.org/docs/installing-ocaml#install-platform-too... the process breaks down with an error when trying to install utop due to a path separator error, which one has to fix manually (at least that was the case last time I tried). By comparison, installing Python or Rust on Windows is a breeze.
Never played with OCaml, but I spent the past few days learning about F# (my understanding is that it inherits a lot from OCaml). Tooling seemed great: I used JetBrains Rider; VSCode and Visual Studio are also options. Support seemed great: good official docs; good book choices. Ecosystem seemed great: entire .Net class library.
I’m been on the JVM for 20+ years, but an opportunity came up to leverage some of my other experience to get some CLR work… and I dove in.
F# has diverged from OCaml a bit, but they're still very similar.
I mentioned in a top-level comment that F#'s "lightweight" syntax is basically what I want when I use OCaml. I know ReasonML is a thing, but if I'm writing OCaml I don't want it to look more JavaScripty - I prefer syntax like "match x with" over "switch(x)" for pattern matching, for example.
I know some people dislike the way F#'s newer syntax makes whitespace significant, and that's fair. But the older verbose syntax is there if you need or want to use it. For example, something like
let things =
let a = 1 in
let b = 2 in
let c = 3 in
doSomething a b c
Thank you! I knew this, but of course blanked on it when I came up with an Ocaml example.
There are a few other places I prefer F#'s syntax, but overall it's not the reason I'd pick F# over OCaml for a project. It's usually mostly about needing to integrate with other .NET code or wanting to leverage .NET libraries for specific use cases.
Can't lose either way - they're both a please to work with.
I used to fiddle with F#, its tooling is good, but it's interweaved with too much dotnet c# cruft and also there's the dark shadow of Microsoft. I wish it had zero cost abstractions like Rust because most things you write in F# is also slower than C#
Dune is a very powerful and good build system — it can do some very magical and useful things. The only problem is most of these useful features are very poorly documented…
When I first looked at OCaml 15 years ago, it felt so complex and couldn’t wrap my head around it.
Now after almost a decade with Elixir, used to functional patterns and immutable data access, I followed a course on compiler construction in OCaml [1] and it felt surprising easy and straight forward, while my attempts using regular imperative languages feel like I’m wasting time on bureaucracy and boilerplate (i.e. in C, Rust or Python) - pattern matching is such an amazing feature.
I have a theory that anyone who wants to learn OCaml as their first FL will fail miserably because the docs and the user experience is horrible. But if you've spend time learning haskell then it's not that bad. BTW I could read erlang pretty well I started learning OCaml and yet that didn't help me much I felt, maybe because erlang is still much simpler?
picked up ocaml back when prepping for some interview round, didn’t expect much just wanted the functional knowledge. but later used it for advent of code and it just worked so clean. pattern matching, recursion, immutabilitty.. fits those problems naturally. ended up liking the language way more than planned.
Is OCaml still worth learning these days ? Feels like plenty of languages are evolving quite well and most things can be done in imperative langs like Go/Java with pretty concise code and certainly better perf.
Pretty concise code: Go code is full of `if err != nil {...}` song and dance and they seem pretty committed to keeping it that way. Java is stuck with decades of decisions and libraries made in their early days because they can't break backward compatibility. Eg, all the standard library collection types are mutable. And of course, both of them have the 'null pointer' problem, which OCaml doesn't.
Meanwhile OCaml has had the same main type-level tools (record types, variant types) and techniques (pattern matching, first-class functions) since the very beginning and those are still the workhorse till this day.
Certainly better perf: I'd say that really depends on how much tuning has been done. OCaml applications by default are fairly performant and with OCaml 5's multicore support and effect handlers will unlock even more performance wins.
Go is definitely full of these issues. Java has pretty good perf out of the box due to JIT. The libs may be old but they do their jobs really well. Some common ones like Guava are updated as new features become available. Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard. However I do prefer immutability wherever I can get it.
YMMV but I find Java perf less even with the JIT than OcAml/F# .NET/etc for tuned code which generally is what matters when performance is a concern. The auto-boxing, lack of proper generics, etc really make it hard to do re-use in a performant way especially around math like apps, especially if they use any of the "Big" boxing types. There's too much heap allocation you can't avoid. Better than say Node/Python but even F# in .NET will generally do better here in my testing with inline templating/stack types/spans/etc.
Languages with immutability/lazy seq/etc support built in can be tuned faster than a library (compiler help around sequences/streams rather than pure library based ones), and again the lack of stack types can make some of these immutable collections much slower/take up more memory than other language targets. There's algorithms I can't use in Java which I can use in .NET/Rust/C++/etc without memory penalty or lots of unsafe/hacky code.
Why are all java apps super slow like Intellij and require you to play around with heap memory with things like xmx min max etc?
I write Java code for a living and it's so dependent on frameworks to do many basic things where you can't really reason about the code. Subtle bugs can come from mutability here, nullability there, hidden state in another place and most coding styles rely on these and use them because it is so easy to do. It's possible, but not idiomatic to write immutable stateless code in Java. Coding in Java is now much more pleasant with records, optionals, sealed interfaces and streams, but it's interweaved with old coding styles so that it negates most benefits of the new patterns
> Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard.
Have you worked in language with immutable collections by default? It's night and day -- no more defensive copies, no more weird ImmutableList wrappers (Guava) which will (interface-wise) say they're mutable but will throw at runtime, no worrying about multithreading, cheap subsequences, etc. etc.
The difference is so stark that I would literally choose a worse[0] language(!) over a better one if it had immutable collections by default.
EDIT: Since you mentioned Java in a sibling comment -- give Scala a try and try working with the collections there.
Functional programming is about clarity of expression and reduced cognitive load.
Aside from FP, the Ocaml type system is better than the mentioned ones. From one hand type inference means you have to write out types much less, and from the other hand the type system is more powerful and lets you express more things than Go/Java.
I would say no. Anything you can do in OCaml you could just as well do in Rust and Rust has many many advantages over OCaml. Vastly bigger ecosystem, Windows support that isn't an afterthought, much better documentation, the syntax is quite a lot friendlier, etc.
Really the only reason I can think to use OCaml over Rust is the compile time, which is quite impressive and significantly better than Rust's. But I don't think that's enough to put up with the other downsides.
I don't think the borrow checker is a factor. OCaml has aspects that are equally painful to learn.
Also if you know Rust you won't really learn much by learning OCaml except "oh that's where that Rust feature came from". Rust stole all the good features from OCaml.
> most things can be done in imperative langs like Go/Java with pretty concise code
Which is why learning OCaml will make you a better programmer even if you then go back to Go/Java. You'll most likely never learn how to do those things without taking that step.
> and certainly better perf.
If you implement the same algorithm in both, it will be faster in Java. But you're more likely to find the better algorithm working in OCaml.
Look at the latest stack overflow developer surveys. It will tell you how much the international community chooses to use (or not) ocaml. To your question, that's people deciding whether it's worth learning.
Yeah but most of the time you learn a language because it changes your way of thinking. I want to pick OCaml for my next project, almost did. But decided against since Java had an ecosystem, tooling and really good performance.
I mostly work with JS and last month picked up learning Zig and building things with it. Zig ecosystem is still early but fun to play around, plus the community folks are helpful with answering my noob questions
Very nice site, but it seems to expect you to be following along with some other resource. The exercises each have links under the details tab, but the links are broken, and I cannot find the web pages they are supposed to be linking to.
BTW how about learning to use Reason, an OCaml compiler fronted with an alternative (and arguably nicer) syntax? Is it popular enough to be worth creating a "tour" app?
> It involves the use of an obscure, French programming language
ROFL! As if the “French-ness” of OCaml were a thing in any shape, form, or way. But anything that doesn't originate in good old America has to be grotesquely exotic.
The trading firm Jane Street is the big OCaml shop, they have a great podcast about all their tech. Each episode is someone from a team talking about the tool they've built, and their whole ecosystem is pretty much bespoke OCaml tooling.
The article isn’t a very technical one. I’d wager when they say tooling they mean any in house program they use as a tool, as opposed to what we as programmers would think of, like compilers, dev tools etc.
Ocaml has a pretty robust ecosystem of good dev tools and build tools.
If you're talking about me (GP), I meant that Jane Street has built an entire ecosystem around OCaml, from their customer-facing and backend software to traditional OCaml tooling (like build systems). That being said, all I know is from the podcast I linked. I haven't touched OCaml (yet?) myself.
The VS Code plugin is, like, 90% of the developer experience of most devs. The fact that it's rock-solid in OCaml should automatically bump us up to at least a B grade. Meanwhile the dune build system is powerful and flexible, and compile times are actually blazing fast, unlike Rust's famous slow builds. So yeah, there are pros and cons on each side, I wouldn't say it's a clear win.
Probably the biggest sectors where functional programming is used are finance and crypto (which is arguably finance). Some companies use OCaml itself, other companies might use other languages like Haskell where OCaml knowledge would be valuable.
OCaml is like nim, not many ppl knows about, but it is one those tech once over the learning curve it just gives developer an extra edge.
It is a very good alternative to memory safe language such as Rust and Swift. It is just NOT backed by big corporations. Which some might see it as a disadvantage, IMHO it is an advantage. Look at Perl, Linux, Hono all initially made by one guy.
With out a big group, golden handcuffs and corporate politics, things might actually gets done.
Nowadays, I don't think Linux is 100%, community-driven only software, considering it also has backup from big corps like Intel, IBM, Oracle, etc etc.
In the similar way, most programming language implementations used in industry (Java, C#, Go etc) also have big corps backup.
My main job is mobile app development, and OCaml definitely lacks significant menpower on this side, so if I were going to use it for my job... perhaps backend stuff? Or what?
Current industry uses are largely in specialist areas including compiler engineering, static analyses, formal verification systems, and systems programming in critical domains.
As someone interested in learning OCaml, this felt like a pretty inaccessible introduction.
Having seen "A tour of Elm,"[0] I really prefer that style. The left-hand side (what English readers read first) is an explanation of the concept, then the right side is the code, and the explanation gives you enough details to complete the code.
This introduction doesn't really explain anything, as I guess it assumes you've learned OCaml elsewhere and are just here to practice.
I tried the first exercise, and it felt more like a math problem than an exercise to teach a programming concept:
>Suppose that a variable x exists and is an integer.
>Define a variable x_power_8 that uses three multiplications to calculate x to the power of 8. The only function you are allowed to call is the (*) operator.
>Hint: use auxiliary variables.
So, at first I thought I was supposed to just call multiply eight times, and then I realized that they said you can only call multiply three times. So, you're supposed to do let a = x * x; let b = a * a; let x_power_8 = b * b. But that feels really contrived to me and not like anything I'd write in a real application, even a toy one. If the idea is teaching variables, why not just ask me to declare a variable that represents x plus 1?
[0] https://a-tour-of-elm.axelerator.de/#JSFunctions
Whatever the purpose of that site is, “Learn OCaml” isn't it. That's a bad title, there is nothing in there that helps a beginner learn OCaml. It's more like a series of tasks where you already have to know OCaml to various degrees.
This is a much better starting point: https://ocaml.org/docs
Using the search engine of your choice, you can find many more sources just looking for "learn ocaml".
> This introduction doesn't really explain anything, as I guess it assumes you've learned OCaml elsewhere and are just here to practice.
Indeed the link is a not an introduction to OCaml but a demo instance of Learn-ocaml which is framework for building online exercise websites to complement (online or physical) lectures. This is why the instance is hosted on the OCaml Software Foundation website rather than ocaml.org: the demo is not targeted to learners but to teachers.
For historical context, I'm pretty sure "A Tour of Elm" is inspired by the similarly formatted and similarly excellent "A Tour of Go".
https://go.dev/tour/
In ocaml you would rather do something like this: let x_power_8 = (let a = x*x in let b = a*a in b*b);
a, b variables are just used for computing x_power_8, you don't need them outside of this scope. I think the point of the exercise is to use variable binding, though I agree the website doesn't explain much
Clicking on the introduction dropped you directly into a programming problem... where you actually needed to know some ocaml.
Context is needed... at least some explanation or bridge examples, like... why and what do I need to navigate this particular web landing page.
Website feels like an author exercise in ocaml for js web plugin.
I have been checking out the online books "OCaml from the very beginning" and "Real World OCaml".
"that feels really contrived to me and not like anything I'd write in a real application"
If that bothers you, you shouldn't be learning ocaml. Look at the latest stack overflow developer surveys. A vast majority of developers and real applications never touch ocaml.
> If that bothers you, you shouldn't be learning ocaml.
That's not what OCaml is like, at all. You clearly hate it, for whatever reason. Fine, have it your way. But popularity contests on SO are not an argument and they explain nothing.
"Thoughts on Rust vs. OCaml" (2020), https://news.ycombinator.com/item?id=24223018
Thanks, I finally understand monads!
OCaml is nice. I like it a lot.
But arguably F# (whose original name was OCaml.NET) is underrated. It improves on OCaml in a number of areas (better pattern matching, computation expressions, namespace support) but more importantly, F# solves OCaml’s biggest problems: lack of decent libraries and subpar tooling.
With F# you get instant access to thousands of high quality NuGet packages which includes everything from fast web servers to highly performant json deserialisation, and you can use some of the best IDEs, tooling and debugger around (JetBrains Rider is outstanding IMO).
F# suffers from the Microsoft association unfortunately, even though Microsoft barely cares about it and provides minimal support for it, most good things about F# are developed and maintained by the community. But the perception exists, and many think it’s still Windows only
I’ve recently been doing a lot of F# development, I do my work on a Mac, using Rider and OCI dev containers, and the code is deployed on Kubernetes, and honestly I don’t remember the last time I enjoyed a programming language and development tooling so much.
My dayjob involves a lot of Java, but the problem I'm working on seems to be a really good fit for a functional language. I've played around with Erlang, Elixir, Clojure and F#. The problem is that I'm always worried about getting stuck somewhere along the process and then end up regretting the decision to not use something more mainstream.
But F# seems to be a real beauty.
Generally you won't get stuck with F#, unless you would of got stuck with C# also. The escape hatch is there, with its pros/cons. The pro is mentioned - the con being that this is where F# gets im-pure and someone with experience would immediately have patterns/team standards to deal with the boundary/usage. C# libraries generally don't have this problem (e.g. Collections, Connection Libs/SDK's, etc) since you invoke them like any other function/object - C# frameworks which invoke your code (e.g. ASP NET Core) you typically need standard code patterns to allow most of your F# code to remain pure/simple.
In general though I prefer the .NET runtime than the JVM in its current state - you can go a little bit lower level when required in hot code without going unsafe (value types, spans, etc).
If your day job is Java, learn Scala 3. It will be a mind-expanding experience.
I highly recommend this resource- OCaml Programming: Correct + Efficient + Beautiful [0]. It is very friendly, fund, and informative. It is one of the proverbial 'mind expanding' stuff.
[0]: https://cs3110.github.io/textbook/cover.html
Highly recommend this as well. Michael Ryan also has a playlist where he goes over the first book of the "Software Foundations" series:
https://www.youtube.com/playlist?list=PLre5AT9JnKShFK9l9HYzk... https://softwarefoundations.cis.upenn.edu/
A great resource for those looking to learn Rocq.
Wow, thanks for sharing. Now I will finally scratch my software proofs itch.
___
Typo in GP: "fun" instead of "fund"
I like OCaml a lot - but I think I like F# a little more. They're very similar, since F# as essentially Ocaml running on the .NET VM.
I know some people dislike the fact that F# lacks OCaml's functors, but I can see why they weren't included. Due the the way F# integrates .NET classes/objects, I can accomplish more or less the same thing that way. In some ways I prefer it - a class/type full of static methods has the same call syntax as a module full of functions, but gives me the option of overloading the method so it'll dispatch based on argument types. Having everything that's iterable unified under IEnumerable/Seq is nice, too.
Having said all that, I still enjoy OCaml a ton. One thing I wish I could have is F#'s updated lightweight syntax brought over to OCaml. I think ReasonML is great, but after using it for a while I realized that what I really want isn't OCaml that looks more like JavaScript. What I want is OCaml that looks like OCaml, but a little cleaner. F# gives me that, plus, via Fable, compilation to JS, TypeScript, Python, and Rust. And via the improved native AOT compilation in .NET 9, I can build fast and reasonably small single-file executables.
Despite all that, I still try to dive in OCaml whenever it's a decent fit for a problem for the problem I'm trying to solve. Even if it's a little quirky sometimes, it's fun.
> F# as essentially Ocaml running on the .NET
IMO, a language without proper modules, GADTs, or (now) an effect system, does not seem to me like it could plausibly be described as "essentially OCaml". Your point about having ad hoc polymorphism (outside of an object system) is another good point about why F# really is not OCaml on .NET.
Not to mention the difference of being trapped in (or having the luxury of, as you prefer) .NET vs. compiling to native binaries.
Glad you like F# tho!
Loved using OCaml for a compiler course at uni when I was a student. But I've always felt that the tooling side is pretty rough, especially on Windows. Opam recently added Windows support, but it involves installing MinGW, and when following the official docs https://ocaml.org/docs/installing-ocaml#install-platform-too... the process breaks down with an error when trying to install utop due to a path separator error, which one has to fix manually (at least that was the case last time I tried). By comparison, installing Python or Rust on Windows is a breeze.
Never played with OCaml, but I spent the past few days learning about F# (my understanding is that it inherits a lot from OCaml). Tooling seemed great: I used JetBrains Rider; VSCode and Visual Studio are also options. Support seemed great: good official docs; good book choices. Ecosystem seemed great: entire .Net class library.
I’m been on the JVM for 20+ years, but an opportunity came up to leverage some of my other experience to get some CLR work… and I dove in.
F# has diverged from OCaml a bit, but they're still very similar.
I mentioned in a top-level comment that F#'s "lightweight" syntax is basically what I want when I use OCaml. I know ReasonML is a thing, but if I'm writing OCaml I don't want it to look more JavaScripty - I prefer syntax like "match x with" over "switch(x)" for pattern matching, for example.
I know some people dislike the way F#'s newer syntax makes whitespace significant, and that's fair. But the older verbose syntax is there if you need or want to use it. For example, something like
should still work in F# like it would in OCaml.> F#'s "lightweight" syntax is basically what I want
It's actually not that far off. For definitions that don't need to be self-referential you can use 'and':
Thank you! I knew this, but of course blanked on it when I came up with an Ocaml example.
There are a few other places I prefer F#'s syntax, but overall it's not the reason I'd pick F# over OCaml for a project. It's usually mostly about needing to integrate with other .NET code or wanting to leverage .NET libraries for specific use cases.
Can't lose either way - they're both a please to work with.
F# tooling is much, much better than OCaml's
I used to fiddle with F#, its tooling is good, but it's interweaved with too much dotnet c# cruft and also there's the dark shadow of Microsoft. I wish it had zero cost abstractions like Rust because most things you write in F# is also slower than C#
Even in Linux, I'd say the tooling is a bit rough, dune and the new lsp are going in the right direction though.
Dune is a very powerful and good build system — it can do some very magical and useful things. The only problem is most of these useful features are very poorly documented…
Would be great to get concrete feedback on the docs, because a lot of energy has gone into improving them in the last 2 years: https://dune.readthedocs.io/en/stable/index.html
The sluggishness of setting up new opam switches is definitely limiting in my experience
When I first looked at OCaml 15 years ago, it felt so complex and couldn’t wrap my head around it.
Now after almost a decade with Elixir, used to functional patterns and immutable data access, I followed a course on compiler construction in OCaml [1] and it felt surprising easy and straight forward, while my attempts using regular imperative languages feel like I’m wasting time on bureaucracy and boilerplate (i.e. in C, Rust or Python) - pattern matching is such an amazing feature.
1: https://cs3110.github.io/textbook/cover.html
I have a theory that anyone who wants to learn OCaml as their first FL will fail miserably because the docs and the user experience is horrible. But if you've spend time learning haskell then it's not that bad. BTW I could read erlang pretty well I started learning OCaml and yet that didn't help me much I felt, maybe because erlang is still much simpler?
Not trying to deny your experience, but Rust also has match.
https://doc.rust-lang.org/rust-by-example/flow_control/match...
picked up ocaml back when prepping for some interview round, didn’t expect much just wanted the functional knowledge. but later used it for advent of code and it just worked so clean. pattern matching, recursion, immutabilitty.. fits those problems naturally. ended up liking the language way more than planned.
Is OCaml still worth learning these days ? Feels like plenty of languages are evolving quite well and most things can be done in imperative langs like Go/Java with pretty concise code and certainly better perf.
Both claims are debatable.
Pretty concise code: Go code is full of `if err != nil {...}` song and dance and they seem pretty committed to keeping it that way. Java is stuck with decades of decisions and libraries made in their early days because they can't break backward compatibility. Eg, all the standard library collection types are mutable. And of course, both of them have the 'null pointer' problem, which OCaml doesn't.
Meanwhile OCaml has had the same main type-level tools (record types, variant types) and techniques (pattern matching, first-class functions) since the very beginning and those are still the workhorse till this day.
Certainly better perf: I'd say that really depends on how much tuning has been done. OCaml applications by default are fairly performant and with OCaml 5's multicore support and effect handlers will unlock even more performance wins.
Go is definitely full of these issues. Java has pretty good perf out of the box due to JIT. The libs may be old but they do their jobs really well. Some common ones like Guava are updated as new features become available. Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard. However I do prefer immutability wherever I can get it.
YMMV but I find Java perf less even with the JIT than OcAml/F# .NET/etc for tuned code which generally is what matters when performance is a concern. The auto-boxing, lack of proper generics, etc really make it hard to do re-use in a performant way especially around math like apps, especially if they use any of the "Big" boxing types. There's too much heap allocation you can't avoid. Better than say Node/Python but even F# in .NET will generally do better here in my testing with inline templating/stack types/spans/etc.
Languages with immutability/lazy seq/etc support built in can be tuned faster than a library (compiler help around sequences/streams rather than pure library based ones), and again the lack of stack types can make some of these immutable collections much slower/take up more memory than other language targets. There's algorithms I can't use in Java which I can use in .NET/Rust/C++/etc without memory penalty or lots of unsafe/hacky code.
Why are all java apps super slow like Intellij and require you to play around with heap memory with things like xmx min max etc? I write Java code for a living and it's so dependent on frameworks to do many basic things where you can't really reason about the code. Subtle bugs can come from mutability here, nullability there, hidden state in another place and most coding styles rely on these and use them because it is so easy to do. It's possible, but not idiomatic to write immutable stateless code in Java. Coding in Java is now much more pleasant with records, optionals, sealed interfaces and streams, but it's interweaved with old coding styles so that it negates most benefits of the new patterns
> Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard.
Have you worked in language with immutable collections by default? It's night and day -- no more defensive copies, no more weird ImmutableList wrappers (Guava) which will (interface-wise) say they're mutable but will throw at runtime, no worrying about multithreading, cheap subsequences, etc. etc.
The difference is so stark that I would literally choose a worse[0] language(!) over a better one if it had immutable collections by default.
EDIT: Since you mentioned Java in a sibling comment -- give Scala a try and try working with the collections there.
[0] Within reason, of course :)
Functional programming is about clarity of expression and reduced cognitive load.
Aside from FP, the Ocaml type system is better than the mentioned ones. From one hand type inference means you have to write out types much less, and from the other hand the type system is more powerful and lets you express more things than Go/Java.
Cant argue with this one. FP code is so much easier to reason about. I was looking at this more from a practical perspective.
I would say no. Anything you can do in OCaml you could just as well do in Rust and Rust has many many advantages over OCaml. Vastly bigger ecosystem, Windows support that isn't an afterthought, much better documentation, the syntax is quite a lot friendlier, etc.
Really the only reason I can think to use OCaml over Rust is the compile time, which is quite impressive and significantly better than Rust's. But I don't think that's enough to put up with the other downsides.
I don't think the borrow checker is a factor. OCaml has aspects that are equally painful to learn.
Also if you know Rust you won't really learn much by learning OCaml except "oh that's where that Rust feature came from". Rust stole all the good features from OCaml.
> Is OCaml still worth learning these days ?
If you haven't learnt anything like it, yes.
> most things can be done in imperative langs like Go/Java with pretty concise code
Which is why learning OCaml will make you a better programmer even if you then go back to Go/Java. You'll most likely never learn how to do those things without taking that step.
> and certainly better perf.
If you implement the same algorithm in both, it will be faster in Java. But you're more likely to find the better algorithm working in OCaml.
Indeed it is.
No. Not even a little.
Look at the latest stack overflow developer surveys. It will tell you how much the international community chooses to use (or not) ocaml. To your question, that's people deciding whether it's worth learning.
Yeah but most of the time you learn a language because it changes your way of thinking. I want to pick OCaml for my next project, almost did. But decided against since Java had an ecosystem, tooling and really good performance.
Yes for your general education I think you should learn a functional language. This is how I think about it, at least.
Is ocaml worth learning today?
I mostly work with JS and last month picked up learning Zig and building things with it. Zig ecosystem is still early but fun to play around, plus the community folks are helpful with answering my noob questions
Yes.
Very nice site, but it seems to expect you to be following along with some other resource. The exercises each have links under the details tab, but the links are broken, and I cannot find the web pages they are supposed to be linking to.
Maybe this helps https://dev.to/yawaramin/practical-ocaml-314j
Do these exercises go with a book?
The only (obvious) option is to begin solving problems.
If someone does not already _know_ OCaml, I fail to see how this is a way to learn.
A better title might be "Practice OCaml"
BTW how about learning to use Reason, an OCaml compiler fronted with an alternative (and arguably nicer) syntax? Is it popular enough to be worth creating a "tour" app?
This seems a site geared towards programming exercises, and not actually teaching OCaml.
Is this Jane Street propaganda?
Careful, Jane Street propaganda could be anywhere nowadays https://www.economist.com/finance-and-economics/2025/06/26/j...
> It involves the use of an obscure, French programming language
ROFL! As if the “French-ness” of OCaml were a thing in any shape, form, or way. But anything that doesn't originate in good old America has to be grotesquely exotic.
The Economist is a British newspaper. Maybe they would find BBC Basic a less obscure language.
https://archive.ph/u10ol
Jane Street propaganda would be better looking
If I learned OCaml, what type of prospects would I have?
Fairly seasoned generalist, mostly writing Go these days. Lots of plumbing with LLMs etc.
Would love to learn something new but am driven by a goal in mind (ie OCaml exposes me to "X industry")
Is that a thing?
The trading firm Jane Street is the big OCaml shop, they have a great podcast about all their tech. Each episode is someone from a team talking about the tool they've built, and their whole ecosystem is pretty much bespoke OCaml tooling.
- https://signalsandthreads.com/
(It's one of three programming podcasts I consistently listen to these days, the others being On The Metal and Developer Voices.)
Bespoke tooling makes me think that the standard tooling is lacking. How does it compare to Rust's tooling?
The article isn’t a very technical one. I’d wager when they say tooling they mean any in house program they use as a tool, as opposed to what we as programmers would think of, like compilers, dev tools etc.
Ocaml has a pretty robust ecosystem of good dev tools and build tools.
If you're talking about me (GP), I meant that Jane Street has built an entire ecosystem around OCaml, from their customer-facing and backend software to traditional OCaml tooling (like build systems). That being said, all I know is from the podcast I linked. I haven't touched OCaml (yet?) myself.
lol
imagine everything that's good about Rust tooling but significantly less good or non-existent instead
(the VS Code plugin for OCaml is actually decent though)
The VS Code plugin is, like, 90% of the developer experience of most devs. The fact that it's rock-solid in OCaml should automatically bump us up to at least a B grade. Meanwhile the dune build system is powerful and flexible, and compile times are actually blazing fast, unlike Rust's famous slow builds. So yeah, there are pros and cons on each side, I wouldn't say it's a clear win.
Probably the biggest sectors where functional programming is used are finance and crypto (which is arguably finance). Some companies use OCaml itself, other companies might use other languages like Haskell where OCaml knowledge would be valuable.
You can see a list on the OCaml website of companies using it, or read some success stories (https://ocaml.org/industrial-users).
Jane Street would be one of the big names that also sponsors a bunch of events / resources.
OCaml is like nim, not many ppl knows about, but it is one those tech once over the learning curve it just gives developer an extra edge.
It is a very good alternative to memory safe language such as Rust and Swift. It is just NOT backed by big corporations. Which some might see it as a disadvantage, IMHO it is an advantage. Look at Perl, Linux, Hono all initially made by one guy.
With out a big group, golden handcuffs and corporate politics, things might actually gets done.
Lots of cool stuff does seep out of Jane Street, though. See for example https://oxcaml.org/ as probably the most recent very public example
Nowadays, I don't think Linux is 100%, community-driven only software, considering it also has backup from big corps like Intel, IBM, Oracle, etc etc.
In the similar way, most programming language implementations used in industry (Java, C#, Go etc) also have big corps backup.
My main job is mobile app development, and OCaml definitely lacks significant menpower on this side, so if I were going to use it for my job... perhaps backend stuff? Or what?
See https://ocaml.org/industrial-users
Current industry uses are largely in specialist areas including compiler engineering, static analyses, formal verification systems, and systems programming in critical domains.
> If I learned OCaml, what type of prospects would I have?
At one point, I believe KDE[0] had OCaml integrations and/or community support.
0 - https://kde.org/
Learning OCaml exposes you to the sadomasochist industry, that's about it.
name checks out: iLoveOCaml
[dead]