[wg-parallel] About Lwt and Async

Yaron Minsky yminsky at janestreet.com
Wed May 1 01:42:35 BST 2013


On Tue, Apr 30, 2013 at 8:26 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch> wrote:
> Le mardi, 30 avril 2013 à 22:15, Yaron Minsky a écrit :
>> It's a beautiful dream, but it sounds implausible to me.
>
> I don't dream, I write code. But, glancing over the discussion, I
> guess there are factors at that play that are not purely technical
> here.

For sure.  For example, the size of the community that already knows
and uses a given library or toolchain plays an important role, which
is more than a purely technical questions.

That said, my objection to your proposal is essentially technical.
Writing a layer that abstracts over Lwt and Async seems highly
problematic.  I think it's hard to build such an abstraction that is
performant, reliable, easy to reason about, and flexible enough to
attach to a wide variety of applications.

That said, this is the kind of objection that is easily overcome by
code!  I'd be very curious to see what such an abstraction looked
like.  I'm sure such a thing is not impossible --- after all, Async
and Lwt both abstract over multiple other concurrency primitives, like
select, libev and epoll.

>> 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 don't think that's the point. I guess when you read/use code that
> you are not happy with it's just sane to not depend too much on
> it. That may be painful in the short term but more rewarding in the
> long term (which is what I'm interested in).
>
>> But this represents only a small part of the concurrent code that
>> one writes, and so only solves a small part of the problem.
>
> The question is which amount of the concurrent code you write is
> really application independent. I don't have the answer but my bet
> on that is that it's actually quite few. You may have a few
> concurrency patterns but I don't see how this couldn't be provided
> the asynchronous libraries themselves using the asynchronously
> "agnostic" primitive libraries.
>
> But that may require a different mindset (especially one that is not
> tied to the application one is currently writing).

I don't understand what you mean by "application independent".  There
are of course lots of application-independent libraries written in
Async (and Lwt too), from communication mechanisms like Async-RPC to
code for setting up TCP servers and clients in the Tcp module, to
logging facilities like Async's Log library.  But these libraries all
depend on the error handling, concurrency and performance semantics of
Async.

y


More information about the wg-parallel mailing list