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 release of OCaml 5.0 marked the end of the Global Interpreter Lock (GIL) era, introducing native support for shared-memory parallelism (Domains) and direct-style concurrency via Algebraic Effects. However, this paradigm shift creates a friction point for production engineering. The OCaml ecosystem has spent over a decade building on monadic concurrency libraries, primarily  Lwt  and  Async . These libraries rely on "function coloring"—where asynchronous functions return a specific wrapper type (e.g.,  'a Lwt.t )—infecting the entire call stack. Engineers must now decide: Do we continue paying the "monad tax" with Lwt, or do we migrate to  Eio , the effects-based IO library that promises direct-style syntax, structured concurrency, and parallel scalability? The Root Cause: Monadic Concurrency vs. Effect Handlers To make the right architectural decision, you must understand how the runtime behaves in both scenarios. 1. The Lwt Model (Cooperative Monads)...