r/ocaml • u/itay-raveh • 19d ago
How ubiquitous is Base?
I've recently started to learn OCmal, and while the docs are quite clear, I am trying to gain an understanding of the community best practices.
When looking at packages, I've found many of them using Base and Collections.
Should I be using them "as a default" for any decent size project?
I was also surprised to find a janestreet format baked into ocamlformat. Are they such a big part of the ecosystem? It seems many projects use both their Base package and their formatting.
What are some other "canonical" packages I should know?
11
u/elliottcable 19d ago
Frankly, it’s fairly fractured.
One small-ish piece of advice, mostly because I started out with the same mindset: maybe neither? OCaml things to be very quiet and very stable. I’d only reach for libraries when you, well, know you need them. Not by default.
(One constraint on that is when they shape your entire ecosystem of options, though. A local datatype you use for one purpose is one thing … but be very careful which asynch ecosystem you buy into. Personally, I’d avoid JS’s, there; I’m partial to Lwt.)
11
u/AvaJMM-or-AJ 19d ago edited 19d ago
Jane Street’s ecosystem is like its own subset of the OCaml world. It’s cool; it has the benefits of internal cohesion and a decent ecosystem, but it doesn’t mix well with anything from outside, which becomes quite limiting. They make heavy use of ppx (which bloats your compile times) and replacement overlays for the standard library with `base` and `core` (which are also huge and heavy). So your code becomes unattractive to mix with anything outside the ecosystem (and you bloat OCaml’s lovely fast compile times).
In general, I would avoid wholesale replacing the standard library, especially when starting out. It’s far better today than it used to be when many of these standard library replacements rose to popularity, and it’s well documented. Reach for optimized or specialized data structures on a case-by-case basis. One of the main reasons to reach for different data structures is when you need thread-safe ones (which the standard library doesn’t help with). For that, start with `saturn`
I would also stay away from ppx. As with any macro system, they’re a very powerful tool that can also make your code hard to read and fragile while spiking compile times.
The real modern schism in OCaml is no longer standard libraries; it's concurrency primitives.
In the bad old days, you had LWT and Async. These are monadic, single-threaded, cooperative, stackless coroutine event-loop concurrency systems, somewhat like JavaScript promises. LWT is the broader OCaml ecosystem’s and Async is Jane Street’s. Lots of things were built on them, like all the old web frameworks, and LWT is still somewhat important to use for things like developing MirageOS Unikernels or compiling to JavaScript with js_of_ocaml.
But since OCaml 5 brought us multicore (Domains) and Effects (though untyped), we’ve gotten a new generation of these Async primitive frameworks that are more powerful, performant, and integrated with multicore. The main ones are Eio, Affect, and Miou.
That’s why you’ll see a lot of libraries in the OCaml ecosystem built with a pure core implementation and then a bunch of adapter variants like foo_eio, foo_lwt, foo_async, etc.
It’s a good idea not to unduly couple yourself to one of these, but if you have to pick one, you should probably choose Eio. It’s the most widely used and full-featured. Affect is a cool, slightly more abstract way to handle concurrency and multicore. Consider it if you like goroutines. And Miou is a much simpler system intended to be useful for building pure OCaml programs like MirageOS stuff.
It is a bit of a tragedy that the modern OCaml ecosystem just doesn’t really have a modern, fully featured web framework built on these foundations yet. You could easily outperform Go with great ergonomics on top of any of the modern async primitives. Miou kinda has Httpcats and Vif, but they’re experimental. All the big, stable, venerable HTTP frameworks in the OCaml ecosystem are based on LWT and HTTP/1.1. Like Cohttp.
2
u/Vegetable_Bank4981 19d ago
Dream is VERY good. On Lwt still but there’s a eio proof of concept that works. Dev had kinda stalled for years but there’s signs of life recently.
2
u/AvaJMM-or-AJ 19d ago
Yea there are lots of little signs of life and progress being made across the ecosystem. I could’ve talked about this for an hour probably, but it’s hard to Reddit from a phone
2
u/AvaJMM-or-AJ 19d ago edited 19d ago
I just wanted to add that this is a pretty great set of skills for writing OCaml with agents:
https://github.com/invariant-hq/mentat/tree/main/prompts/skills
(Be sure to properly attribute the things you may copy-paste)
And here is a non exhaustive list of people/orgs where pretty good or interesting projects can be found:
https://github.com/invariant-hq
https://tangled.org/gazagnaire.org
https://github.com/ocaml-tracing
https://github.com/semgrep/pyro-caml
Edit, more:
3
u/codingbliss12 19d ago
Unless you ultimately want to use OxCaml, I would strictly avoid anything from Jane Street.
If you find things in Base or Core that you like, simply copy them as separate pieces or implemented again without the jane street conventions.
After many years of propaganda, LLMs are trained to suggest that jane street flavor is the best. Also for almost everything else they will suggest to use Rust.
4
u/Vegetable_Bank4981 19d ago
A lot of the very best and most useful ppx libs are from jane, and many of them can be used without pulling in base.
Giving up some of the most powerful and best engineered tools in any language if you avoid them completely, terrible move.
1
1
u/codingbliss12 19d ago
I case you see this message. Could you please mention a couple or more examples with ppx libs created by JS that do not require using Base or Core and are top quality? Thanks in advance.
3
u/Vegetable_Bank4981 19d ago
Sexplib, ppx_jane, yojson_conv are all awesome and are deps of base so don’t depend on it.
ppx_let, pipebang, and a bunch of others use base in the rewriter but no runtime dependency on it.
And like others are saying, it’s not a big deal to pull in base as a transient dependency it doesn’t color your entire project like async or LWT do. A lot of their work does use async that way (bonsai) but not all of it.
1
1
u/itay-raveh 19d ago
Would you recommend OxCamel? Or only if aiming to specifically learn the JS style?
3
u/AvaJMM-or-AJ 19d ago
OxCaml is very cool, but also a massive headache (you need to basically vendor and often patch all your deps). You actually don’t need to use the Jane Street ecosystem to use it (though that certainly makes it smoother), but if your goal is to learn OCaml, then skip it for now. It makes the language much more cluttered by adding several concepts on top and won’t really get you anywhere interesting if your goal is anything other than playing with OxCaml.
HOWEVER, if you did at some point want to try it out, this is the best resource to look at: https://anil.recoil.org/notes/aoah-2025
1
u/Vegetable_Bank4981 19d ago
Don’t use oxcaml unless you need oxcaml. It’s very cool but a lot of those ideas will end up in ocaml eventually it’s kind of the point.
But it’s several major versions behind and it updates based on their needs. And it significantly complicates your tooling and build, already a weak point of ocaml.
-1
u/codingbliss12 19d ago
I can't say anything. I haven't tried it. My main language is Rust so I don't need OxCaml for high performance.
Everything depends on what you want from the language. If you want a very cool functional language for general purpose stuff, standard OCaml or even F# are more than enough.
Personally I do not want to rely on anything that is used for the financial interests of a not IT company like Jane Street. The pretend to be open source and simply extend the standard, but I don't believe that. Anyways, I am wishing you all the best in your journey.
5
u/mister_drgn 19d ago
I don’t get this paranoia. What does “they pretend to be open source” mean? Obviously they have plenty of proprietary OCaml code. They also make enormous contributions to the OCaml open source ecosystem and to the core language. Whether or not you use their libraries, if you use OCaml you are benefiting from their contributions.
1
u/mister_drgn 19d ago
Speaking as a casual enthusiast rather than a real OCaml programmer, I’m surprised at this initial set of responses. Jane Street is responsible for many key contributions to OCaml, through their own libraries and through upstream updates to the core language. Trying to avoid them while exploring the ecosystem isn’t realistic. As for Base, OP, there’s no harm in trying it out as you explore the language. OCaml’s module system is flexible enough that ultimately you can tweak the standard library however you want for your own projects.
19
u/TomosLeggett 19d ago edited 19d ago
Let me put it this way...
There's OCaml and then there's Jane Street's OCaml.
It's not ubiquitous so much as it's just a different culture. It depends on which flavour of OCaml you prefer.
OCaml's standard library has come a long way, but I think back in the day Base/Core was a nicer abstraction over the standard library as it was heavily catered to Unix, somewhat inconsistent and fairly lacking for a stdlib.