Interesting OCaml Articles

Anyone whoā€™s been following this blog probably saw this coming:

Itā€™s an interesting read and hopefully can be used as constructive criticism in order to improve the state of the OCaml ecosystem.

4 Likes

A bit tough to read but he hasnā€™t said anything unfamiliar.

Iā€™m trying to put myself in his position and wondering what Iā€™d do differently. Probably the biggest thing is Iā€™d use js_of_ocaml based adapters to call into Node.js libs to fill in ecosystem needs, rather than considering the much more laborious work of binding C or Rust libs.

1 Like

Iā€™d like to know what about Lwt the author struggled with. The model it provides is not very unique or different from what many developers already do with Node.Js.

For improving our documentation, what if we made it clear on ocaml.org that weā€™re looking for more documentation and a clear process on how to get your docs onto ocaml.org? Sometimes I have a free weekend and now I think I could use that to write docs but itā€™d be nice to know if I write it, it will make it to someplace useful rather than just a blog post.

2 Likes

I wonder if the real deal-breaker was the GCE APIs. I mean, everything else is workable ā€“ just takes a little coding. I suppose (not having looked) that the GCE APIs are exposed via GRPC ā€“ and thatā€™s a non-starter right now in OCaml, sooo ā€¦

2 Likes

My current thinking on documentation is to note each tutorials existence on ocamlverse, but house the actual tutorial as a heavily commented example program (maybe using https://github.com/lindig/lipsum), residing directly within the library that itā€™s documenting in an additional ā€œtutorialsā€ directory of the package. That addresses the code rot problem without adding a lot of complexity to the ocamlverse implementation, since the library author can build the tutorial source as part of regular CI.

1 Like

I think as a community if we want good docs weā€™ll also have to come to terms with how diverse Ocaml programmers are. At the very least, Lwt and Async. Also Core vs Batteries vs containers. There are various reasons to prefer one over the other but those reasons are likely not important to a new user.

1 Like

Followup to yesterdayā€™s article:

2 Likes

Re: more documentation/tutorials, this has been mentioned here before but Iā€™d like to +1 both using asciinema and uploading them to asciinema.org.

Example, this simple tutorial on installing opam on Ubuntu:
https://asciinema.org/a/36250

Briefly: asciinema is a tool that records your terminal. You just run (e.g.) asciinema rec bash and it produces a very space efficient, copy-and-pasteable video that you can upload to asciinema.org or host yourself. After years of struggling to follow along in YouTube tutorials which have blurry console screens this is a breath of fresh air.

4 Likes

Funny that I took the opposite journey as Dark as regards F# versus OCaml. In various ways I also prefer F# - I think the syntax is a little cleaner and having access to the .NET standard library and ecosystem is obviously useful. Mailboxes are nice too for concurrent programming! But I donā€™t like having to butt up against the OO system all the time while Iā€™m trying to think functionally (I felt the same way with Clojure many moons ago) and the experience with implementing anything non-trivial on Linux with .NET Core was not fun. Constant DLL hell when trying to develop with a Postgres driver, for example.

I do think the Darklang posts raise some good points. I am also surprised that they found Lwt tricky to use, or they found functorized hashtables difficult. Ergonomically I find them absolutely perfect as soon as youā€™ve created your desired module from the functor.

4 Likes

The only major GCP API I can think of that only speaks GRPC is Cloud Bigtable. All of the big ones like GCE, Spanner, GCS and Datastore, also speak HTTP with JSON encoded data.

The blog post specifically mentions the lack of a spanner library. I think some of the challenges to developing one are that the API surface is quite large, and testing it would cost money.

To be honest, both OCaml and F# are a poor choice for a cross-platform language. First has many obstacles on Windows platforms while the second - on anything besides Windows. Rust, on the other hand, is the first class citizen everywhere.

3 Likes

The cross platform story for F# should get better now that dot net core is the primary dot net version thatā€™s used everywhere. After reading this post I tried setting up F# on a Mac and it was quick and easy to get up and running (with decent editor setup via LSP + neovim).

2 Likes

butt up against the OO system

This exactlyā€¦ The least bad option for me for using other ecosystems backend libraries is probably ocaml talking to golang libraries. I havenā€™t looked up whether this actually is possible currently

I canā€™t compare OCaml to F# hereā€“Iā€™ve never used F#ā€“but when I was learning OCaml, I read through the description of the Jane Street maps/hashes etc. and kind of ran screaming. The online docs for the JS maps were even scarier. Yes, partly itā€™s that I was coming from Clojure, where you can just throw anything into a map, because itā€™s dynamically typed and maps are designed that way. But still ā€¦ I thought, I know itā€™s harder with OCaml because it needs to be type safe, but still there has to be a better way. So it wouldnā€™t surprise me if F# maps were easier to understand.

Biggarā€™s description of the F# ecosystem reminds me of Clojure. Maybe in some nearby possible world OCaml-Java could have played a similar role. Or maybe, per @mbacarella:

For me, the article highlights the need for there to be an informal way for people to signal that they have private source code that they will share with others directly, upon request. I am sure someone has google cloud bindings, just no one wants to put such a library on GitHub, because they donā€™t have the time to answer issues or support the library. Generally, if people put more of their libraries on GitHub (or more open system like codeberg), but marked their repo as ā€œarchivedā€, that would be a good way to signal other people can copy it, while telling others not to bother contacting for support

2 Likes

GitHub allows switching off the wiki, issues, and PRs per repo.

3 Likes

[full disclosure: I lived thru the first ten years of Java at IBM, and watched as the ā€œJDKā€ grew to engulf library-after-library. I will always prefer the OCaml or Perl model of user-contributed libraries, b/c monoculture led to bugs and lack of flexibility. And I can always write my own version of whatever missing package. I mean, itā€™s just not that damn hard.]

I wonder if what heā€™s really complaining about is lack of a large commercial backer (Java has many, F# has MSFT, Rust has ā€¦ ? (maybe none, which would disprove this thesis)).

Repeatedly in both the linked articles, as well as his comparison of OCaml to Rust, it seems like heā€™s complaining that there arenā€™t enough ā€œlibraries that he needsā€ available. And to be sure, for a commercial organization, this could be a dealbreaker. [A quick Google search shows what appear to be Perl APIs for Spanner, so thereā€™s at least an existence proof for a community-backed language having such support.]

I do wonder how Rust does it. Are there more commercial users? Are there big commercial backers?

1 Like

I donā€™t think Rust is much closer to OCaml when it comes to ecosystem than Java, F# or Go for that matter. And actually the commercial baker in Goā€™s case seems to prove your point:

This is a chart showing the number of pull requests to repos in a given language on GitHub. Itā€™s not a good measurement of popularity but maybe it is a good measurement of the ecosystem health.

2 Likes

Well he also complains about the syntax and that ā€œI saw a team struggle with OCaml, and for good reason. Language tutorials are extremely poor in OCaml compared to other languages; theyā€™re mostly lecture notes from academic coursesā€. I have some sympathy: for example, writing code to an interface is a fairly basic starter for a programmer but not intuitive in ocaml: the most direct equivalent requires module signatures with abstract types and sharing constraints and possibly functors (the last three of which are unavailable in F#), and there is nothing in the ocaml websiteā€™s ā€œLearnā€ section explaining how to achieve this kind of equivalence.

That is probably for good reason. In ocaml it is generally more idiomatic to think of such things in terms of higher-order functions and combinators, or pattern matching on variants. There is a cognitive jump involved.