Programming Tutorials

  The shift from Lwt (cooperative threading via monads) to Eio (direct-style parallelism via Effect Handlers) represents the most significant paradigm shift in the OCaml ecosystem in a decade. While the promise of "no more monads" is alluring, the migration path is fraught with invisible dangers. The primary friction point is not syntax; it is the fundamental change in the execution model. In Lwt, context switches only occur at explicit bind points ( >>=  or  let* ). You implicitly relied on this behavior for atomicity. In OCaml 5 with Eio, code running on multiple domains introduces true parallelism. Consequently, logic that was thread-safe by accident in Lwt becomes a race condition in Eio. This post details the rigorous migration of a stateful, asynchronous module from Lwt to Eio, ensuring structured concurrency and thread safety. The Why: Monadic Cooperative vs. Direct Structured Concurrency To port correctly, you must understand the mechanical divergence. Lwt (...

  The OCaml ecosystem has fundamentally shifted. For over a decade,   Lwt   (and   Async ) provided the standard for concurrency via cooperative threading and the   Promise   monad. While effective for single-core I/O, this model became a bottleneck with the release of OCaml 5. Legacy Lwt applications are largely single-threaded. They cannot utilize the true parallelism offered by OCaml 5’s Multicore runtime without spinning up heavy system processes or relying on complex work-stealing pools. Furthermore, the "colored function" problem—where  Lwt.t  infects every function signature—creates cognitive load and obfuscates stack traces. We are migrating a compute-heavy IO service from Lwt to  Eio  (Effects-based IO). Eio leverages OCaml 5's algebraic effects to provide direct-style concurrency (no monads) and seamless domain (core) utilization. The Root Cause: Monads vs. Effects To migrate effectively, you must understand the mechanical diff...