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 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, 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 < >>> 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 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 >>>> >>> >>> >> >