Interesting OCaml Articles

Yes, C# is also garbage collected

Yes but its GC is optimized for extremely low collection times at the expensive of eating more memory. It isn’t too hard to get a Go program into a state where it’s memory explodes and it eventually runs out. This does mean it’s runtime tends to be quite fast in the common case, C speed or so.

I thought this might be of interest since AFAIK the backend is implemented in OCaml:
https://darklang.com/

1 Like

The morning paper blog has a new post on Mergeable replicated datatypes, a paper ((by Gowtham Kaki, Swarn Priya, KC Sivaramakrishnan, and Suresh Jagannathan, 2019; PDF) explaining the design of a git-inspired approach to programmable distributed datastructures. The code is in OCaml, and I would assume that Irmin was an inspiration for this work.

1 Like

I have published a blog post about the OCaml release process: Testing OCaml releases with opamcheck.

3 Likes

Found on Lobste.rs: Mark Karpov writes yet another Haskell vs. OCaml for old time’s sake. I found it worth a read and a mention here.

p.s. He spends a bit of time in the intro lamenting the lack of a conventional Unicode string library for OCaml, and I feel that pain acutely, especially since I’m the author of an unconventional one, i.e. the Ucs_text module in my Orsetto project.

2 Likes

Not really an article, but interesting to see the performance comparison using multicore OCaml

1 Like
2 Likes
3 Likes

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.