[wg-parallel] About Lwt and Async

[Yaron Minsky]

Jeremie, I have another thought about trying to bring Lwt and Async
together: knowing the two engines well as you do, do you think it
makes any technical sense to basically bolt an Lwt skin on top of
Async?  i.e., create an alternate version of the Lwt module where 'a
Lwt.t = 'a Or_exn.t Deferred.t, so as to let one share the core
scheduler.  This could allow code written to Lwt to run on top of
Async's engine.

I suspect it would be quite a large effort, and perhaps the Lwt
community would have no interest in using the result of it, so I'm not
saying it's worth doing.  I'm just wondering if you think it's a
technically feasible project.

y

On Tue, Apr 30, 2013 at 8:58 AM, Yaron Minsky <yminsky at gmail.com> wrote:
> On Tue, Apr 30, 2013 at 8:43 AM, Vincent Balat
> <vincent.balat at univ-paris-diderot.fr> wrote:
>> Hi,
>>
>> I want to thank very much Yaron and all of you for taking time to try to find
>> a solution to this problem. I also want to remind the position of the Ocsigen
>> project on this list (and make it clear that we do not plan to switch to
>> Async).
>>
>>> I'm not sure that the right goal is "to make them evolve so they are
>>> close enough".  If we're going to end up with just one implementation,
>>> it's hard for me to see how it's not going to be Async, because Jane
>>> Street is not going to be able to move away from Async as a practical
>>> matter.
>>
>> I understand but I think it is even worse for Lwt, because it is used by many
>> projects (representing several hundreds of thousand of lines, written by many
>> people). Ending up with one implementation is unfortunately a very unlikely
>> hypothesis. That's why I proposed, not to drop one of the implementation, but
>> to try to converge in term of features and semantics, in order to make it
>> easier to adapt libraries for one or the other, and thus limit the impact of
>> the schism Async is creating.
>
> Unfortunately, I don't see how having two libraries with different
> implementations and similar semantics is much of an improvement over
> the current state of affairs.  Using functors for making libraries
> portable over the two is no way to live!
>
> I understand your reluctance to switch away from Lwt --- surely,
> dealing with the migration would be disruptive and would take
> significant time and effort.  Indeed, our own situation is that we
> have a few million lines of code using Async, 100 or so active
> developers internally, and many mission-critical applications that
> depend on the details of Async's semantics and performance, so moving
> away from it is a non-starter for us as well.
>
> In any case, I think the question of how to maximize interoperatbility
> between Async and Lwt seems on topic.  Beyond that, we're interested
> in understanding what can be done to make Async more broadly useful to
> people outside of Jane Street.
>
> y
>
>> It is not possible to ask Lwt projects to switch to the current implementation
>> of Async, because there are too many projects and most of them will probably
>> just do nothing.The Ocsigen Web framework itself is a large piece of code,
>> relying a lot on very precise details of the semantics of Lwt. We are
>> currently working on ambititous projects that have a much higher level of
>> priority. Besides, we cannot take this decision for all our users.
>>
>> If Jane Street does not want to switch to Lwt (which would be the best
>> solution for the community but I understand that it is not easy), the only
>> possibility I see to end up with one implementation is to make Async evolve so
>> that it could really be used in some way as an exact replacement for Lwt.
>>
>> In the current state of things, I want to make it clear that Ocsigen will not
>> switch to Async, and will not abandon Lwt users, and continue to encourage
>> people using Lwt rather than Async, in order to keep a consistency between
>> libraries.
>>
>> But we would be happy if Jane Street could help avoid a split of the OCaml
>> community ... The solutions you propose are a very good first step, and we
>> appreciate it.
>>
>> Vincent
>>
> _______________________________________________
> wg-parallel mailing list
> wg-parallel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-parallel