Peel the Onion: Why OCaml Seems Difficult When it’s so Easy
——
OCaml is not inherently complex. It’s actually one of the simplest languages I’ve ever used — much easier to reason about than JavaScript or TypeScript, in my opinion.
So why do so few people use it?
I’ve been writing about OCaml for a while now. Coming from the web-dev world and transitioning into systems programming, I’ve noticed something:
The learning experience of OCaml feels like peeling an onion.
Let me explain.
We Teach OCaml Like an Onion… Instead of a Ladder
Learning OCaml today often means dealing with:
- too many layers at the same time
- too many concepts too early
- too many assumptions about prior knowledge
We should teach OCaml the same way math teachers introduce concepts to kids.
When you teach natural numbers, you don’t immediately dive into rationals, imaginaries, coordinate transforms, or rotations.
You give learners only what they need now so they can build intuition first.
It’s not “lying.”
It’s good pedagogy.
If we want newcomers to adopt OCaml, we must meet them where they are — not where we are.
And if we’re worried about beginners misusing advanced tools or producing bad code, the solution is simple:
Just don’t show them everything at once. Limit the toolset until they’re ready.
Teach Through Examples
Although we love these topics, most newcomers don’t want to build a parser, an interpreter, or a compiler toy.
They just want to write a program that runs.
The Rust community understands this perfectly:
- Your first contact with Rust is running a small project.
- You don’t know borrow-checking rules.
- You don’t know how MIR works.
- You don’t know lifetimes.
That’s the mindset we should adopt: Show first, explain later.
Let intuition grow through repeated practical experience.
Newcomers Matter (More Than We Admit)
Most OCaml users today come from highly specialized backgrounds — formal methods, academia, compilers, fintech, research labs — and that’s great.
But if we want the community to grow, we must reach a different kind of newcomer:
- web developers
- backend engineers
- self-taught programmers
In other words: people who simply want to try a new language.
DX Matters: Small Details Have Massive Impact
Velocity matters — especially for beginners.
Sometimes improving the experience means removing a single flag from a command.
If we want more people to fall in love with OCaml, we must:
- reduce friction in the first 10 minutes
- streamline project creation
Think of it this way: less configuration = less documentation for us 
Too Many “OCamls” for a Beginner
Choice is good.
But for beginners, too much choice feels like fragmentation.
We should provide one clear, opinionated, beginner-safe path.
They can explore everything else later.
Coming from the web world, I’ve learned that technologies don’t win because they’re elegant.
They win because they align with existing intuition.
React is a perfect example.
It didn’t win because it’s the best design (I personally think it isn’t).
It won because it felt like JavaScript — it matched developers’ existing mental models.
OCaml has the opposite problem:
There isn’t one OCaml. There are multiple OCamls.
Beginners have no idea which version they’re supposed to follow.
This creates paralysis:
- “Which style is the real OCaml?”
- “Will what I learn today work tomorrow?”
- “Why does this example look nothing like that other example?”
My Current Goal in the Community
This is why I’ve been writing OCaml content:
to help newcomers enter the language comfortably.
It’s a work in progress, but my personal mission is to:
- teach OCaml through examples
- show first, explain later
- prioritize intuition
- reduce conceptual overhead
- build a smooth path for people coming from mainstream backgrounds
Final Thought
If we want OCaml to grow, we need to onboard people the same way we teach children mathematics — or the same way Rust introduces new developers:
with intuition, clarity, and progressive complexity.
OCaml deserves that.
Newcomers deserve that.
OCaml documentation maintainers deserve that.
aren’t working all the time.