> 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, 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 > . However, > we have quite a few projects that needed this abstraction, so duplicating > this code in each repo seemed wrong. Thus we developed future > , which was recently released in opam. > > > > On Mon, Mar 7, 2016 at 9:06 AM, Yotam Barnoy > 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 > > 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 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 >>> >> >> >