Eff vs Effect: Trade‑offs for Diagnosing Intermittent Connection Pool Exhaustion

Goal

Determine whether the Eff monad or the Effect monad provides clearer, actionable type‑level information for diagnosing intermittent connection‑pool exhaustion in a service that experiences bursty load.

Constraints and uncertainty

The Eff monad (purescript‑eff) tracks individual effects via extensible rows, giving fine‑grained visibility of which allocation or release operation is performed, but it requires manual effect ordering and produces larger type signatures. The Effect monad (purescript‑effect) collapses all effects into a single type, simplifying signatures and working smoothly with the newer Aff async model, yet it hides the specific effect being executed, making it harder to reason about resource usage such as pool leaks. Both systems interoperate through runEffect and runEff, but mixing them in a codebase can obscure which effects are tracked, especially when debugging intermittent resource exhaustion. The PureScript team has marked Eff as deprecated in favor of Effect for new projects, yet many existing libraries still expose Eff‑based APIs, leaving developers to weigh migration effort against library compatibility. Version assumption: PureScript compiler 0.14.0 or later, where Effect is the preferred system.

Open questions

1. Which effect system yields more actionable type‑level information for detecting pool leaks under intermittent load?
2. Does the added verbosity and manual effect ordering of Eff outweigh the simplicity of Effect when the primary concern is diagnosing intermittent resource exhaustion?
3. How does interoperability between Eff and Effect affect the ability to trace pool usage across a mixed codebase that includes both legacy Eff‑based libraries and new Effect‑based code?