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

[Ivan Gotovchits <ivg@ieee.org>]

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

> 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: 9525 bytes --]