[wg-parallel] About Lwt and Async

Daniel Bünzli daniel.buenzli at erratique.ch
Tue Apr 30 18:25:21 BST 2013


(sorry for the top post I was not subscribed)

To be honest I'm neither content with either lwt nor async. I actually toyed with my own implementation of these concepts, that may, or not, be released in the future. A few hints of what lead me to that are given here [1]. 

That being said I would like to stress that a lot of foundational libraries can avoid making a choice *without* functorizing as Yaron (doesn't) suggest.

Notably codecs can be made both lwt and async friendly by following this pattern [2] (the repo has a toy example, see the readme), which I already implemented for Unicode and JSON decoding [3,4]; xmlm will adopt it once I get time to work on the library again; the Vg library on which I'm currently working on [5] also uses that pattern.

Given the positions on both sides, I actually think we should take that "schism" as a chance rather than a curse. Striving for independence from the concrete asynchronous programming mechanism (with or without functorizing) and cutting down on dependencies in foundational libraries may actually lead to software that is more composable, adaptable and reusable in the long term.

My opinion is that most of the time choosing a particular asynchronous programming library should be a choice left to the developer of *applications* not to the developer of libraries --- but I have a bias towards small and focused libraries rather than "solve everything frameworks".

Best,

Daniel

[1] https://github.com/dbuenzli/fut/blob/master/RATIONALE
[2] https://github.com/dbuenzli/nbcodec/blob/master/RATIONALE
[3] http://erratique.ch/software/uutf
[4] http://erratique.ch/software/jsonm
[5] https://github.com/dbuenzli/vg/




More information about the wg-parallel mailing list