# OCaml future development **URL:** \ **Category:** Community\ **Created:** [September 7, 2020, 3:23pm UTC](https://discuss.ocaml.org/t/ocaml-future-development/6375 "2020-09-07T15:23:35Z")\ **Posts on this page:** 1\ **Showing post:** 24
**Author:** ![cemerick](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/cemerick/32/1383_2.png) [@cemerick](https://discuss.ocaml.org/u/cemerick)\ **Post date:** [September 8, 2020, 5:25pm UTC](https://discuss.ocaml.org/t/ocaml-future-development/6375/24 "2020-09-08T17:25:10Z")
There is a process for bringing new modules into stdlib, as evinced by a recent thread: [Adding Dynamic Arrays / Vectors to StdLib](https://discuss.ocaml.org/t/adding-dynamic-arrays-vectors-to-stdlib/4697) Asking for a “batteries-included” stdlib akin to those provided with Go or Python seems like a non sequitur. The OCaml maintainers have quite explicitly chosen a minimalist library strategy, allowing/encouraging users to find the best solutions to problems that aren’t essential to the language’s implementation. (To wit, even what might be considered a “low level” detail like lightweight concurrency is serviced by popular community libraries, lwt and Async.) Asking or hoping for a change in this disposition is pretty unrealistic, and would likely disrupt those that have made bets on OCaml _because_ of its approach in this regard. To be clear, none of this precludes the development of libraries (or suites of them, constituting a framework for your domain(s) of interest) becoming popular enough to be _de rigueur_ standards (viz. as Rails was/is for Ruby). I think hoping for progress there is more realistic, and quite desirable. --- _[View the full topic](https://discuss.ocaml.org/t/ocaml-future-development/6375)._