HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
c-cube
ocaml-containers
OCaml2014–2020
c-cube / ocaml-containers

ocaml-containers

A lightweight, modular standard library extension, string library, and interfaces to various libraries (unix, threads, etc.) BSD license.

4Distinct people
4Mentions
0Explicit recommenders
523GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A lightweight, modular standard library extension, string library, and interfaces to various libraries (unix, threads, etc.) BSD license.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2014-11-25 18:09:09 UTC to 2020-01-26 12:59:16 UTC.

012014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101

What Hacker News says

4 sources
I've been writing a lot for Reason and OCaml last few years, but the majority of it target BuckleScript and React. My front-end bias alone means it's a better stack than any other alternatives mentioned in this thread (and I even find it more productive than TypeScript), so take it with a grain of salt. I do use ocaml-graphql-server and such a lot to write small services, but I often don't interact with databases or build complex backends that would require a bigger back-end webdev ecosystem. Most of my native development happens far from the cloud, and mostly around CLI and GUI tools for which I adore OCaml and recently Reason (https://github.com/revery-ui/revery). > cumbersome types, typeclasses, lack of type annotations sometimes hurts I've grown to really like the explicitness of OCaml actually. Nothing implicit or circular, and I can
Read the rest
just read a module from top to bottom. The lack of type annotations don't bother me as much with tools such as Merlin, and I find that the amazing type inference lets me prototype code as fast as dynamic languages. > - what are the current reasonable options for a StdLib? Last I checked, the default lib was still very poor, while JaneStreet's I found barely documented. I use Containers (https://github.com/c-cube/ocaml-containers/), Lwt, and a few other small libraries like Rresult and Bos pretty heavily. For a big application with many contributors I'd still suggest giving Core another try as it's very well thought out and extensive (compared to npm-style dozens of dependencies you need to introduce with different API designs). I must say that even though I'm pretty used to reading type signatures and jumping to interface files for documentation (and even prefer it to tutorial style docs in markdown), and wouldn't say Core's documentation is _poor_, I agree with you at some level. Because of how it's built and split up across different packages and modules, it gets pretty tiring having to power through many levels of indirection every time you want to look something up. > - Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java). I find that, compared to some other languages I've used, my naive and readable implementation in OCaml last much longer before I need to optimize it. I do use Lwt_preemptive threads that call C code and subprocesses often, but usually because of the nature of the problem I'm solving and not as a parallelization technique. > - What's an example of a recent codebase written in "modern" OCaml / Reason? Most open source projects I can think of are libraries and tools such as compilers, but here are some real-world applications off the top of my head: - https://github.com/onivim/oni2 (native, desktop) - https://github.com/SVdotCO/pupilfirst (bucklescript, react) - https://github.com/Schniz/fnm (native, CLI) Some of the cool stuff I saw in the wild: https://github.com/osener?language=reason&tab=stars https://github.com/osener?language=ocaml&tab=stars Hope this helps! I think with the recent convergence around tools such as dune, opam, esy, it is a great time to start writing OCaml again.
In Restack: Full-Stack ReasonML
I'm not convinced that Base will solve our problems. It's not, afaik, more portable, more lightweight, more performant, or more feature-full than [containers](https://github.com/c-cube/ocaml-containers) (which has reached 1.0 and also does a bit of IO and Unix, as a stdlib extension). In addition to that it's not compatible with programs that use the stdlib right now, so the fragmentation will stay for a long time (unlike for build systems where you "only" have to change the build scripts, not the code itself). (Of course I'm biased too, I wrote containers ^^)
In Exploring ReasonML and functional programming
Oh, great, yet another library of data structures that introduce incompatible abstractions with both the standard library and the 3 other big libraries of data structures[1,2,3], that is exactly what the OCaml ecosystem needs! :D More seriously, though, at least the naming convention is consistent. It looks a bit heavy on signature-indirection. I would really prefer if they used a standard iterator (gen[5] and sequence[6], for example, or the future one in the stdlib[7]) and settled for one serialization method (such as sexp) and get formatters everywhere. Also, please use ocamldoc or odoc[4] for your documentation. The one generated here is really terrible, even for OCam^W Reason standards. [1]: https://github.com/c-cube/ocaml-containers/ [2]: http://batteries.forge.ocamlcore.org/ [3]: https://github.com/janestreet/base [4]: https://gith
Read the rest
In A set of efficient persistent immutable data structures for Reason and OCaml

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.