[wg-parallel] About Lwt and Async

[Yaron Minsky]

It's a beautiful dream, but it sounds implausible to me.  I think one
might as well propose writing programs in a way that is independent of
the programming language.  This is doable in some small ways on the
margin, but it's not a practical approach.

I do think that some libraries, like the parsing associated with XML
or JSON, can be made independent in this way.  But this represents
only a small part of the concurrent code that one writes, and so only
solves a small part of the problem.

In the end, I do still think we will be better off if we can settle on
one major concurrent programming library.

y

On Tue, Apr 30, 2013 at 1:25 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch> wrote:
> (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/
>
>
> _______________________________________________
> wg-parallel mailing list
> wg-parallel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-parallel