Skip to content

Comparison and Analysis

Cross-ecosystem comparison of algebraic effect systems and closely related effect platforms.

Last reviewed: February 16, 2026.


Reading This Table Correctly

Many production systems called "effect systems" are not full algebraic handler systems. This page separates:

  • full handler semantics (operations + handlers + resumptions)
  • effect tracking/runtime systems that solve adjacent problems

The Effect System Trilemma

Every effect system navigates tension between several competing concerns. No system achieves all simultaneously.

ConcernBest-in-classWhat it costs
Performanceeffectful, eff, Koka (evidence passing), OCaml 5 (native continuations)Loses pure interpretation (effectful); stalled development (eff); untyped effects (OCaml 5)
Expressivenessheftia, Koka (row-polymorphic), Effect (TypeScript)Conceptual complexity; newer/less battle-tested; runtime overhead (Effect-TS generators)
Simplicitybluefin, Ox, OCaml 5 EioExplicit handle threading (bluefin); no effect handlers (Ox); no static effect typing (OCaml 5)

2026 Comparison Matrix

System / FamilyEffect TypingFull Handlers?Continuation StrategyKey StrengthsCurrent Limits
KokaRow-polymorphic effect types with inferenceYesSelective CPS + evidence-style compilationStrong theory/implementation alignment; practical effect inferenceSmaller ecosystem than mainstream platforms
Eff / Effekt / research languagesVaries, usually explicit effectsYesInterpreter or compiler-specificClean semantics and experimentation velocityResearch-oriented tooling/ecosystem
OCaml 5 runtime + EioRuntime effects (no effect rows in function types)Yes (runtime handlers)Native one-shot continuations/fibersDirect style, strong multicore story, production language integrationStatic effect typing remains an open language-design direction
[Haskell effectful] / cleffType-level effect listsNot full algebraic handlers (by design)Reader/environment dispatch over IOExcellent practical performance and ecosystem interopNo general continuation-based algebraic effects
Haskell continuation-backed libraries (eff, bluefin-algae)Library-specificCloser to full handlersGHC delimited continuation primopsRuntime-backed control effects in HaskellAPI/maintenance maturity varies across libraries
Haskell hefty-style line (heftia, Theseus)Algebraic + higher-order structureYesElaborate HO effects before FO interpretationStrong soundness story for HO interactionsNewer ecosystem; higher conceptual load
[Scala ZIO] / Cats EffectTyped channels/typeclassesNo (not algebraic handlers)Fiber runtime on JVMProduction-grade concurrency/runtime toolingDifferent abstraction goal than algebraic handlers
Scala Kyo / TurboLiftOpen effect channelsHandler-inspired algebraic modelRuntime/library-specificDirect-style ergonomics with effect trackingRapidly evolving API/model compared with mature stacks
Scala 3 capabilities / capture checkingCapability/capture typesN/A (language capability system)Language-level type disciplinePromising static reasoning for authority/effectsExperimental status in Scala 3.8
Effect (TypeScript)Effect<A, E, R> style channelsHandler-inspired library modelGenerator/runtime encodingStrong industrial ergonomics in JS/TS ecosystemRuntime overhead model differs from native runtimes
WasmFX / stack-switching targetsLow-level typed continuation substrateTarget-level primitivesRuntime/VM continuation supportCross-language compilation path for handlersProposal/toolchain maturity still evolving

Encoding Strategies Compared

Performance Characteristics

EncodingBind CostDispatch CostMemoryGHC Optimization Dependency
mtl (transformers)O(n) per layerO(1)LowModerate
Free monadO(1) amortizedO(n) per handlerHigh (tree)Low
Freer monad (freer-simple)O(1) amortizedO(n) per handlerHigh (tree)Low
Carrier fusionO(1)O(1) (fused)LowHigh (inlining critical)
ReaderT IOO(1)O(1)LowLow (concrete monad)
Delimited continuationsO(1)O(1)Low-MediumNone (by design)
Hefty algebrasO(1)O(1) per phaseMediumModerate
Row-polymorphic evidence passingO(1)O(1) via evidenceLowN/A (Koka compiler)
Native continuations (OCaml)O(1)O(1)Low (one-shot)N/A (OCaml runtime)
Coroutine-based (Rust)O(1)O(1) via coroutine yieldLow-MediumN/A (LLVM)
Generator-based (TypeScript)O(1) amortizedO(n) per yieldMediumN/A (V8/JIT)

Semantic Properties

EncodingCaptures ContinuationsSound HO EffectsPure InterpretationMultiple Same-Type Effects
mtlNoN/A (no HO as data)YesNo (fundeps)
Free monadVia tree inspectionNo HO effectsYesYes
Freer monad (freer-simple)Via tree inspectionNo HO effectsYesYes
Carrier fusionLimitedPartial (unsound cases)YesYes
ReaderT IONoPartial (unsound cases)NoYes
Delimited continuationsYes (native)Yes (eff)No (IO-based)Yes
Hefty algebrasYesYes (fully sound)YesYes
Higher-order freer (Theseus)YesYes (consistent)YesYes
Row-polymorphic (Koka)Yes (multi-shot)N/A (first-order only)YesYes (labels)
Native continuations (OCaml)Yes (one-shot only)N/ANo (untyped)Yes
Coroutine-based (Rust)Yes (via coroutine)NoYes (no IO required)Yes
Generator-based (Effect-TS)No (single-shot)N/AYesYes

The Soundness Question

A critical issue that separates effect systems is the soundness of higher-order effects. When a higher-order effect (like catch or local) scopes over a computation that uses algebraic effects (like NonDet or Coroutine), the interaction can produce incorrect results. Different libraries give different answers, and some give inconsistent answers depending on handler ordering.

LibraryHigher-Order EffectsAlgebraic EffectsSound Interaction
polysemyYes (Tactics)PartialNo -- documented unsound cases
fused-effectsYes (carriers)PartialNo -- same class of issues
effectfulYesNo (no continuations)N/A (avoids the problem)
cleffYesNoN/A
effYesYesYes -- consistent delimited control semantics
heftiaYesYesYes -- elaboration ensures soundness
TheseusYesYesYes -- order-independent interpretation
KokaN/A (first-order only)YesN/A -- no higher-order effects; first-order algebraic effects are sound by construction
OCaml 5N/AYes (untyped)N/A -- no static guarantees; soundness is the programmer's responsibility
EffN/A (first-order only)YesN/A -- reference semantics by Plotkin/Pretnar
FrankYes (multihandlers)YesYes -- ambient ability with CBPV ensures consistent semantics

The effectful/cleff approach sidesteps the problem entirely by not supporting algebraic effects (no continuation capture). This is a pragmatic choice that works well for most applications.


Where the Frontier Actually Is

1. Semantic soundness

The hardest unsolved practical issue is still the interaction of higher-order effects, resumptions, and resource management. Work since 2023 (Hefty and follow-ups) is the most important movement here.

2. Performance without semantic collapse

The current best results avoid a single universal technique:

  • Evidence-passing style dispatch for common operations
  • Selective continuation capture when needed
  • Runtime primitives where available

This combination replaces the old "handlers are elegant but too slow" narrative.

3. Parallel and resource-sensitive handlers

2024-2025 papers push handlers into parallel, affine, and temporal regimes. This is a major shift from earlier single-threaded, mostly first-order benchmarks.

4. Mainstream language integration

OCaml and GHC runtime support, plus Wasm target work, suggest long-term success depends on runtime/compiler cooperation, not only library encodings.


Practical Selection Guide

If your primary goal is production reliability today

  • Haskell: effectful/cleff when continuation-heavy algebraic semantics are not required
  • Scala: ZIO or Cats Effect for mature runtime ecosystems; TurboLift for handler-centric typed effects
  • OCaml: Eio on OCaml 5 for direct-style concurrent systems

If your primary goal is semantic expressiveness of handlers

  • Koka and research languages (Eff/Effekt)
  • Haskell hefty-style research line (heftia, Theseus) for sound HO composition
  • Experimental continuation-backed Haskell libraries (eff, bluefin-algae)

If your primary goal is language/runtime research


Misleading Comparisons to Avoid

  1. "Effect system" vs "algebraic handlers" as if equivalent.
  2. Microbenchmark-only rankings that ignore modular compilation and optimizer boundaries.
  3. Treating "typed effects" as binary: many systems intentionally trade static tracking for runtime ergonomics.

Sources