I think Bonsai is great, and we’re ramping up our investment in it internally.
My main caution about Bonsai is that development has moved really fast since the last stable release, and the bleeding edge version has really changed a lot and is a lot better. So you might want to either take the trouble of getting set up with our bleeding-edge release, or wait for the next stable release later this year.
y
VS Code OCaml Platform extension uses Base. We use basic data structures mostly, and it’s a quite pleasurable experience. It’s interesting there is no Option.unwrap_or_else: 'a option -> ~default:(unit -> 'a) -> 'a, which we provide in the extended version of Base.Option.
That may be only tangentially related to the topic, but I wonder about the differences in their approach to incremental computations between Jane Street’s Incremental and Rust’s salsa.
It’s great to hear that you’re increasing investments in bonsai! With the huge churn in the rescript/reason ecosystem, it might be a good time to try bonsai out.
I’m having problems getting bleeding edge bonsai to build locally, sadly. I’ve posted my query on a more appropriate thread: Compiling Bonsai - #17 by sid
Hi Pad, Way off topic so I’ll be brief. There is some info in the early slides from an ADSL talk. There is not much info around at this point as the implementation is at a stage where it is driven by a narrow internal application focus, and the work to make it generally usable hasn’t yet been done.
Well, Jane Street also, sort of… 
At Solvuu, we use Base/Core, Async, and sexp. We also depend on ppx_jane to include all of your ppx extensions. The ones we use the most are ppx_sexp_conv, ppx_let, ppx_compare, and ppx_expect. Our internal coding guide includes a rule called JANE-STREET-FIRST, which is defined as “Prefer a Jane Street library whenever they provide one for a given functionality. Seek other libraries only if they don’t.”
Curious, have you ever had to make exceptions to this rule, and what were they?
(In my case the fact that I might want to run something on Windows some day made me select Lwt instead of Async for a small handful of projects, though I prefer Async. That’s the only thing I can think of)
One case is that we have a few libraries that we want to be compatible with OCaml and ReScript. In those, we avoid Base/Core and restrict ourselves to the Stdlib. We don’t have a need for Windows, so have never faced that particular issue.
Historically, we did at one time use Lwt for its compatibility with js_of_ocaml, but we eventually gave up on OCaml for front-end work and switched to JavaScript. (This was a few years ago. We’re back to using OCaml and ReScript now. We’d happily use js_of_ocaml with its Async support, but don’t currently have that need.)
I forgot to mention a couple of other libraries we use: shexp and delimited_parsing.
It would be great if there was a JaneStreet namespace so we know which libraries come from Jane Street.
I use their GitHub organization for that.
Indeed, GitHub URLs contain the name of the organization. No need to visit the organization’s page, the org name is visible on each page of the project.
I’m not just trolling here 
, I’m also serious about this issue: a simple contributor editing source code won’t know which modules come from which vendor. They won’t be able to associate the quality or style of some module with Jane Street. It’s poor branding, and not for Jane Street in particular but for all publishers of OCaml source code.
There are also technical merits to having proper namespaces. Those were already discussed elsewhere.
synsh.dev uses Core (kernel) as an Stdlib replacement, as well as ppx_inline_test and ppx_let.
Personally I find that to be a good thing. Code tends to outlive organisation or organisation names. You don’t want to have to change your code the day one marketing genius decides to change the name of a company or if it get acquired by another company. Java reverse dns package names do what you want and in my opinion it’s not that great on the long term.
One thing they could do though is to improve the discoverability of Jane Street opam packages by tagging them with org:janestreet. There are already a few org:* labels, this allows to easily search for packages e.g.
opam list --has-tag org:erratique
opam list --has-tag org:mirage
It’s also quite useful for maintainers for bulk management of your packages or checking them on @kit-ty-kate’s excellent opam health service.
I’m only speculating but it seems there are ways to deal with renames. If changing the namespace to match the latest organization’s name is essential, they can do so and stop releasing code under the old namespace. When a user is ready to upgrade to the new namespace, they could just sed -e 's/oldname/newname/g' or even open both namespaces e.g.:
open Old_namespace (* for the old libraries *)
open New_namespace (* for the upgraded libraries *)
^ These are not modules! Each namespace “provides” only the modules that were installed by the user, so there’s no conflict between modules. There’s a module Old_namespace.A from library A and a module New_namespace.B from library B. Old_namespace.B and New_namespace.A are not installed so the compiler finds no such modules and there’s no conflict between A and B.
Yes it’s always possible to add more bureaucracy in a system ;–)
What’s on my mind mostly is Base, Core_kernel, and Core. I think it’s complicated to make sense of them and to navigate the documentation. Namespaces would eliminate those names. There would be no more Base.List, Core_kernel.List, Core.List. There’d be just JaneStreet.List, JaneStreet.Signal etc. all shipped by a collection of packages of adequate granularity, without overlap. And we wouldn’t care much about the package names anyway. Package managers take care of that. The programmer would care only about namespace and module names.
I agree that namespaces would be useful, but I should mention that the next stable release should make things simpler, in that Core and Core_kernel are now the same library, so there’s only Base and Core to think about.
Does that mean that the next release of core will work on windows?
Yup! One of the big wins from our perspective is that many of our libraries use Core (rather than Core_kernel or Base), and having those available on non-UNIX platforms (for us, JavaScript is the important one right now) is going to make a lot of our code more portable.
y
Awesome, thanks!
I’m using base and core_kernel (need windows support) on some hobby projects.
Took a look at bonsai, but because of needing a different opam repo I didn’t look further at it.