Real World OCaml

What Hacker News says

1. tlavoieNov 2025
   It's probably the path of least resistance if following the Real World OCaml book (https://dev.realworldocaml.org/), which is quite excellent.
   thread
2. crvdgcJul 2025
   Apart from being tied with Jane Street's libraries, Real World OCaml is "deeper" in that it also talks about implementation details. This book has a more "introduction to functional programming via OCaml" vibe. Both are good textbooks with different emphases.

   The main author Michael Clarkson also started a similar lecture series on Software Foundations using Rocq (Coq)[1]. Not sure if that's still updated though.

   [1]: https://github.com/clarksmr/sf-lectures

   Show morethread
3. nobleachApr 2025
   I just had this same thought this morning. I sure do with OCaml was far more popular. Right now, if you're planning a startup, you want something that you can just snap together a bunch of well-tested libraries. You want DB libraries, S3, message queue stuff, Kafka stream stuff. OCaml does have a lot of these things but they just aren't well known. If they exist, they're just poorly documented. This is why people opt for Java/Typescript/Ruby/Python. It's easy to hire devs, and the tools they'll use are fairly well understodd.

   OCaml suffers greatly from a lack of unified practice. There's a YouTube playlist, a Udemy course... an Apress book and those two other ones with camels on the cover. That's about it for stock OCaml. If you want to learn Jane Street flavored OCaml, there's Real World OCaml.

   Show morethread
4. ragneseDec 2024
   You're not far off. This is one of my favorite topics in programming language design discussions, and I have opinions that some may even say are "controversial". For what it's worth, I've been writing Rust in production since 2016 (not 100% of my time since then, but I've had a good amount of experience with some decently long-lived projects of varying complexity).

   First, I assert that Java's checked exceptions are a solidly good feature. Of course it has flaws. The whole rest of the language is also full of flaws, so that's not surprising.

   Second, I assert that there are two things that have caused the vast majority of hate toward Java's checked exceptions: programmers not being taught/shown how and when they're intended to be used, and that oft-circulated interview transcript from 2003 where Anders Hejlsberg asserts that checked exceptions are language design "dead end". I don't think he was right in 2003, and I especially don't think the opinion is correct today in light of how much strong static typing has really gained favor with the programming community. But, that opinion really took off and we spent years and years seeing that assessment repeated as a truism, which I think is why it took so long to finally start experimenting with statically typed failure modes again (e.g., Rust and Swift).

   Now, here's where I'll get controversial about Rust error handling. I'll try really hard to keep this from turning into an entire dissertation, but I'll elaborate if anyone asks.

   It is often a mistake to implement the `From` trait for error types and use the `?` operator everywhere. Error types in an API need to be aware of the context in which they occur, so just converting by type only often doesn't make sense. You may encounter a `FooError` type while your app is doing totally different things, so it's likely that not every `FooError` occurrence means the same thing to whoever is calling into your code. Also, sometimes you can actually handle an error, and getting into the muscle memory habit of just tacking `?` on to everything can lead to mistakenly propagating errors that you might have better handled by doing something else (including perhaps panicking).

   There does seem to be a trend toward automatically adding stack traces in Rust errors. This is completely misguided, IMO. And this may be my MOST controversial opinion: stack traces almost *never* belong in a `Result<>` error type. Result types should be relevant to your "domain" (borrowing the term from "Domain Driven Design" even though I do NOT advocate for DDD in general).

   Think about it this way: designing an API is about abstraction. So if you write a integer division function that takes two arguments and divides them, it might return `Result<i64, DivideByZero>`. If the caller passes in a 0 divisor, then what business is it of theirs to see what your private functions are called, how many of them are called, and what line of your file they were defined on? That's the leakiest of leaky abstractions.

   You might be thinking: "But, if I see an result/error value that I didn't expect while running my program, the stack trace will help me track down the issue!" Yeah, no kidding. So, let's also start adding stack traces to our successful values, too! After, all, if I call my division function and get back a `Result::Ok` with a weird number that I didn't expect, I might want to trace that back, too, right? (This suggestion is sarcastic to prove a point. It should, hopefully, sound ridiculous to add stack traces to every return value from every function.)

   The issue is that Rust's Result (and Java's checked exceptions) require a different paradigm. A Result is in the type signature because it's part of your domain's API design. It's just values. It's not *for* debugging. You use a debugger for that or programmatically panic when something is truly unexpected and get the stack trace from that.

   Which leads to the corollary to the previous controversial opinion: Rust has unchecked exceptions; they're called panics and they are 100% *okay to use* in the vast majority of applications that the vast majority of day-job programmers work on.

   Obviously, context matters, and there are some places where panicking is unacceptable. But, Result is for expected domain failures. Panics are for programmer errors and unrecoverable constraint violations. And I'm not advocating for panics to be "lazy". Rust code that refuses to ever panic (as far as they know, but I hope they aren't indexing any vecs/arrays just in case!) usually leads to overly polluted error types where it ends up being difficult to understand what errors are actually meaningful and what errors are never actually going to happen. Instead of inspecting errors and figuring out which to handle and how, I've seen things just snowball into a giant mess of nested enums with sometimes redundant error "branches" and missed opportunities to actually handle some cases. If you, as the programmer, know for sure that you just added something to a HashMap earlier in your function and you know you didn't remove it, then for the love of all things sacred, just write `map.get("my-key").unwrap()` (or `.expect("message")`--whatever) instead of making the caller have to consider an error that will never happen, is not their fault, and that they can't do anything about!

   And, if you do have a situation where panicking is unacceptable (you must be using `#![no_std]`, right??), then don't make a bunch of different error types for all of the possible programmer bugs. Just make a single umbrella `FatalError` type and use that.

   For further reading, I really like this piece from the book Real World OCaml, which also has a Result type and exceptions: https://dev.realworldocaml.org/error-handling.html. Specifically, the very last section at the bottom of the page, titled: "Choosing an Error-Handling Strategy". (The old version of that page used to be more plain HTML and the sections had anchors so I could link directly to that section...)

   And for further reading about error handling strategy in a no-panic context, I really like the approach described here: https://sled.rs/errors

   Show morethread
5. keyleSep 2024
   I think it was a pretty ambitious first project in OCaml, which is vastly different from the languages you came from.

   I took a similar path years ago and I found your situation akin to mine. The documentation is spotty, full of gaps, particularly for a new comer; although I found some reasonable books that helped "OCaml from the very beginning, 2013" and "Real world OCaml 2nd edition, 2022".

   I love OCaml but I don't see myself going back to it. I love re-reading old code that has been cleaned up. It reads like perfect design. It's satisfying.

   However I found writing OCaml to be painful, battling the syntax and the LSP. The LSP being actively highlighting everything red due to one typo, because the syntax is this way, and it's frustrating... And sure, you can work without LSP support, but it's useful than cmd+tabbing 300 times to run the program and watch it crash on typos. The right balance is to turn it off and turn it back on at times.

   But once finished, and years down the line, re-reading completed OCaml projects is a joy. I'd like to imagine that it made me a better programmer in other languages; due to the type-system-first approach, and transformation of data through functional programming.

   Show morethread
6. nequoJun 2024
   > This is book communism and fails for the same reasons as regular communism. It is in nobody’s interest to do any hard work. If you don’t reward great effort, virtually nobody provides it.

   Counterpoint that is decidedly not motivated by communism:

   https://dev.realworldocaml.org/

   There are many books like it, comprehensive, written with great effort, and free for anyone to read.

   thread