[Caml-list] [ANN] Lwt 3.0.0 – monadic promises and concurrent I/O

[Anton Bachin <antronbachin@gmail.com>]

Greetings fellow Camels,

We are pleased to announce release 3.0.0 of Lwt, the concurrent
programming/promise library.

  https://github.com/ocsigen/lwt

This release makes some minor breaking improvements to the Lwt API,
which were previously announced in release 2.7.0. You can see the
changelog here:

  https://github.com/ocsigen/lwt/releases/tag/3.0.0

The non-breaking changes made to date are separated out into a preceding
Lwt 2.7.1, also released recently. Most notable are compatibility with
OCaml 4.05 and the official announcement of Lwt_result:

  https://github.com/ocsigen/lwt/releases/tag/2.7.1

Release 3.0.0 completes the first test of Lwt's "soft" breakage
cycle [1]: Lwt warns users about upcoming breakage, provides simple
upgrade paths, and gives time to (optionally) adapt before the breakage
actually occurs. Simultaneously, users are invited to visit the Lwt
repository and object to any planned breaking change, or otherwise
contribute their opinions and expertise.

We hope that, going forward, this will give us the flexibility to fix
crufty parts of Lwt in a consensual fashion, without causing unjustified
headaches and surprises. Of course, we prefer to avoid breakage as much
as possible – but, here and there, some things just need to be broken.

3.0.0 factors some of Lwt's optional dependencies fully out into their
own packages [2]. This process will likely continue with factoring out
the Camlp4 extension and the PPX [3]. We are also eyeing the Lwt Unix
bindings, though this requires more consideration.

On the subject of Unix, we are also considering some kind of "merger,"
literal or not, [4] between Lwt and uwt [5], the Lwt-aware binding to
libuv [6]. A combination of a libuv binding and prospective bindings to
Node.js [7] might be the best way to create portable, maintainable I/O
bindings at once for Unix-like operating systems, Windows, and Node.
This work, however, is in an absolutely embryonic stage, and we are not
sure how or where it might go.

Though not immediately relevant to users, work continues on reducing the
internal technical debt of Lwt. We hope this makes contributing to Lwt
easier in the future – that Lwt will not be a forbidding code base.
This should help everyone in the longer term, and it goes hand-in-hand
with the slow writing of the new manual. It seems writing tests, and
refactoring Lwt in places, are necessary to gain the kind of
understanding needed to write a good, thorough manual in the first
place.

The Lwt project welcomes new co-maintainers: Mauricio Fernandez (@mfp)
and Simon Cruanes (@c-cube). Their fresh perspectives and expertise,
both general and specialized, already help the quality of Lwt greatly.

Happy concurrent programming,
Anton Bachin


[1]: https://github.com/ocsigen/lwt/issues/293
[2]: https://github.com/ocsigen/lwt/issues/41
[3]: https://github.com/ocsigen/lwt/issues/338
[4]: https://github.com/ocsigen/lwt/issues/328
[5]: https://github.com/fdopen/uwt
[6]: http://libuv.org/
[7]: https://github.com/ocsigen/lwt/issues/270