Re: [Caml-list] Question about Lwt/Async

[Ivan Gotovchits <ivg@ieee.org>]

[-- Attachment #1: Type: text/plain, Size: 7011 bytes --]

We actually have another work, that heavily intersects with  `Lwt` and
`Async`. It is code named `bap-future`[1], and in short this
is a library to work with asynchronous values. This can be seen, as `Lwt.t`
or `Ivar.t` cleaned up of everything unnecessary.
In the ideal future, the `Future.t` can be used as a common denominator
between `Lwt` and `Async`.

[1]:
https://github.com/BinaryAnalysisPlatform/bap/blob/master/lib/bap_future/bap_future.mli

P.S. It will be also released very soon.

On Mon, Mar 7, 2016 at 9:59 AM, Ivan Gotovchits <ivg@ieee.org> wrote:

> > While I still prefer Async’s interface
>
> Me too, that's why we created an [overlay][1] over Lwt, that provides an
> interface in the style of Core library.
> I'm currently working on releasing this library to opam.
>
> [1]: https://github.com/BinaryAnalysisPlatform/core-lwt
>
> On Mon, Mar 7, 2016 at 9:55 AM, <rudi.grinberg@gmail.com> wrote:
>
>> Since my post was mentioned, I thought I’d chime in.
>>
>> I’ve used both libraries and I’ve found little practical difference
>> between the two. I think porting a codebase from Lwt to Async (and vice
>> versa) is mostly mechanical work.
>>
>> While I still prefer Async’s interface a little more but I think the two
>> main points in my blog post still stand. If portability and maximum
>> interoperability with the community are important to you then the decision
>> is already made in my eyes.
>>
>> On March 7, 2016 at 9:26:41 AM, Ashish Agarwal (agarwal1975@gmail.com)
>> wrote:
>>
>> > Also, what happens to general utility functions that aren't rewritten
>> for Async/Lwt -- as far as I can tell, being in non-monadic code, they will
>> always starve other threads, since they cannot yield to another Async/Lwt
>> thread.
>>
>> There is Lwt_preemptive.detach and Async's In_thread.run to get around
>> this.
>>
>>
>> > It seems that Lwt is more popular in the community outside JaneStreet
>> than Async (if only by looking at its reverse dependencies on
>> opam.ocaml.org). There has been posts about this, for instance
>> http://rgrinberg.com/blog/2014/12/11/abandoning-async/ .
>>
>> I'd be wary of drawing conclusions from one blog post and even from opam.
>> I think the answer is: both are used a lot. Also depends on what you mean
>> by "a user". It's not too useful to count Jane Street's packages and one
>> barely used package on opam both as 1. A lot of code is not on opam.
>>
>>
>> > Is there an existing compatibility library functorized over the
>> intersection of Async and Lwt? That would make being compatible with both
>> much easier.
>>
>> Most people provide this internally for each of their projects, e.g. Cohttp's
>> IO signature
>> <https://github.com/mirage/ocaml-cohttp/blob/master/lib/s.mli>. However,
>> we have quite a few projects that needed this abstraction, so duplicating
>> this code in each repo seemed wrong. Thus we developed future
>> <https://github.com/solvuu/future>, which was recently released in opam.
>>
>>
>>
>> On Mon, Mar 7, 2016 at 9:06 AM, Yotam Barnoy <yotambarnoy@gmail.com>
>> wrote:
>>
>>> Is there an existing compatibility library functorized over the
>>> intersection of Async and Lwt? That would make being compatible with both
>>> much easier.
>>>
>>> On Mon, Mar 7, 2016 at 4:08 AM, Simon Cruanes <
>>> simon.cruanes.2007@m4x.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> It seems that Lwt is more popular in the community
>>>> outside JaneStreet than Async (if only by looking at its reverse
>>>> dependencies on opam.ocaml.org). There has been posts about this, for
>>>> instance http://rgrinberg.com/blog/2014/12/11/abandoning-async/ .
>>>> However, if you're writing a library, it is good taste (if possible) to
>>>> parametrize you code over an "IO" monad that will be easy to instantiate
>>>> with either Async or Lwt (or the trivial blocking monad where 'a t = 'a
>>>> and (>>=) x f = f x) along with the required IO primitives.
>>>>
>>>> Regarding general utility functions, if they do not perform IO or depend
>>>> on (blocking) IO they can be used directly with Async/Lwt (unless they
>>>> really take a very long time to complete).
>>>>
>>>> Le Mon, 07 Mar 2016, Malcolm Matalka a écrit :
>>>> > Yotam Barnoy <yotambarnoy@gmail.com> writes:
>>>> > > Hi all
>>>> > >
>>>> > > I'm thinking about my next project in OCaml, and I'm wondering how
>>>> many
>>>> > > users of OCaml currently use Lwt or Async regularly.
>>>> > >
>>>> > > One of the advantages of OCaml over Haskell (which I'm not crazy
>>>> about) is
>>>> > > the fact that you don't have to constantly be stuck inside a monad.
>>>> > > However, once you want to use these user-level threading libraries,
>>>> you're
>>>> > > essentially tied to a monad. It also means that the usage of any
>>>> other
>>>> > > monad from Lwt/Async code is out -- OCaml doesn't have the monad
>>>> > > transformer infrastructure to layer monads easily as far as I can
>>>> tell (am
>>>> > > I wrong?). I mean, even in Haskell using Monad Transformers is a
>>>> pain (IMO).
>>>> > >
>>>> > > Also, what happens to general utility functions that aren't
>>>> rewritten for
>>>> > > Async/Lwt -- as far as I can tell, being in non-monadic code, they
>>>> will
>>>> > > always starve other threads, since they cannot yield to another
>>>> Async/Lwt
>>>> > > thread. Is this perception correct? If so, this seems to imply that
>>>> you
>>>> > > either write your code to cooperate within these frameworks and
>>>> suffer the
>>>> > > monad, or don't, and make it near-impossible for Lwt/Async users to
>>>> make
>>>> > > use of your code.
>>>> > >
>>>> > > I would like to get an idea of the usage level of these libraries,
>>>> as well
>>>> > > as the burden of writing compatible code, any difficulties etc.
>>>> Also, I'd
>>>> > > like to get a sense of the domains that benefit from these
>>>> libraries. Some
>>>> > > domains (such as gaming) traditionally involve a continuous main
>>>> loop, and
>>>> > > would thus only suffer from the additional overhead of queuing in
>>>> these
>>>> > > libraries.
>>>> > >
>>>> > > -Yotam
>>>> >
>>>> > I mostly use Async.  However, I think most usage of Lwt or Async
>>>> > requires doing as little as possible in these frameworks and using
>>>> them
>>>> > to orchestrate other functions.  For example, I usually try to
>>>> separate
>>>> > parsing of a network protocol from the reading and writing of the
>>>> bytes.
>>>> >
>>>> > --
>>>> > Caml-list mailing list.  Subscription management and archives:
>>>> > https://sympa.inria.fr/sympa/arc/caml-list
>>>> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>>> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>>
>>>>
>>>> --
>>>> Simon Cruanes
>>>>
>>>> http://weusepgp.info/
>>>> key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3  7D8D 4AC0 1D08 49AA
>>>> 62B6
>>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 10631 bytes --]