There is a moment in programming that almost every developer recognizes. A piece of code begins as a simple sequence of ideas: take a value, transform it, return a result. At that stage, everything feels local, direct, and easy to follow. The logic is visible in the structure of the code itself, and reading it often feels close to reading the problem it is meant to solve.
That clarity rarely lasts unchanged for long. Sooner or later, the computation needs something that does not belong to pure local reasoning anymore. It may need to fetch data from a server, handle a failure, wait for an asynchronous result, write a log entry, retry an operation, read configuration, or interact with some external system. At that point, the code is no longer shaped only by the logic of the problem. It also becomes shaped by the mechanics of execution.
This is where things begin to shift. A callback moves the rest of the computation into another function. A promise pushes it into <code>.then(...)</code> and <code>.catch(...)</code>. <code>async/await</code> restores a more direct style, but only because the runtime silently takes responsibility for suspending and resuming the computation behind the scenes. Exceptions interrupt the normal path and redirect control else where. Other abstractions place the computation inside containers or contexts that the surrounding program must now respect.
None of these mechanisms are mistakes. They are useful, necessary, and deeply embedded in the way modern software is written. But they all reveal the same underlying tension: as soon as a program needs something from outside itself, control flow becomes part of the problem. The question is no longer only what should this code do? It also becomes how should this computation proceed when it depends on time, failure, IO, or some external service?
That is the point where algebraic effects become interesting.
The name can sound more abstract than the idea really is. In practice, the intuition is surprisingly natural. A program reaches a point where it cannot continue on its own, so instead of deciding immediately how the needed action must be carried out, it simply requests that action. Something else, a handler, gives meaning to that request. Once the request has been interpreted, the computation continues.
This is the heart of algebraic effects: the program asks for an operation, a handler decides what that operation means, and the computation resumes with the result.
What makes this idea powerful is that it separates two concerns that are often entangled in ordinary effectful code. On one side, there is the intention of the program: what it wants to do. On the other side, there is the interpretation of that intention: how it is actually executed in a given context. That separation may seem small at first, but it changes the way side effects can be organized. Instead of forcing the structure of the whole program to bend around promises, callbacks, exception paths, or other execution machinery, algebraic effects invite us to imagine code that stays closer to direct reasoning, while the runtime or the surrounding handlers take responsibility for the operational details.
This is why algebraic effects are often seen as an elegant response to an old and recurring difficulty in programming. They do not eliminate side effects, and they do not make complexity disappear. What they offer is a different organization of that complexity, one in which the program can remain focused on expressing its needs while handlers determine how those needs are fulfilled.
That is the path this article will follow. We will begin with mechanisms that already feel familiar, such as callbacks, promises, <code>async/await</code>, exceptions, generators, and React Suspense. From there, we will build the core intuition behind three central ideas: effect, handler, and continuation, before looking at why algebraic effects feel close to many existing mechanisms and yet still introduce something genuinely new.
If the term still feels abstract at this stage, that is completely normal. By the end, the goal is for the idea to feel much simpler than the name first suggests:
the program asks,
something handles,
the computation continues.
Read the full article:
<a href="https://helabenkhalfallah.com/2026/03/10/algebraic-effects-from-callbacks-and-promises-to-effect-handlers/" target="_blank" rel="noopener nofollow">https://helabenkhalfallah.com/2026/03/10/algebraic-effects-from-callbacks-and-promises-to-effect-handlers/</a>

Welcome to the "Code, Craft & Community" group! 🚀
Are you a curious 🤔 and passionate ❤️‍🔥 developer? Join this group and gain access to a variety of tools while feeding your mind with valuable knowledge!

Algebraic Effects: From Callbacks and Promises to Effect Handlers