Algebraic Effects for the Rest of Us

They’re not burritos.

Algebraic Effects for the Rest of Us

July 21, 2019

Pay what you like

Have you heard about algebraic effects?

My first attempts to figure out what they are or why I should care about them were unsuccessful. I found a few pdfs but they only confused me more. (There’s something about academic pdfs that makes me sleepy.)

But my colleague Sebastian kept referring to them as a mental model for some things we do inside of React. (Sebastian works on the React team and came up with quite a few ideas, including Hooks and Suspense.) At some point, it became a running joke on the React team, with many of our conversations ending with:

["Algebraic Effects" caption on the "Ancient Aliens" guy meme]

It turned out that algebraic effects are a cool concept and not as scary as I thought from those pdfs. If you’re just using React, you don’t need to know anything about them — but if you’re feeling curious, like I was, read on.

(Disclaimer: I’m not a programming language researcher, and might have messed something up in my explanation. I am not an authority on this topic so let me know!)

Not Production Ready Yet

Algebraic Effects are a research programming language feature. This means that unlike if, functions, or even async / await, you probably can’t really use them in production yet. They are only supported by a few languages that were created specifically to explore that idea. There is progress on productionizing them in OCaml which is… still ongoing. In other words, Can’t Touch This.

Edit: a few people mentioned that LISP languages do offer something similar, so you can use it in production if you write LISP.

So Why Should I Care?

Imagine that you’re writing code with goto, and somebody shows you if and for statements. Or maybe you’re deep in the callback hell, and somebody shows you async / await. Pretty cool, huh?

If you’re the kind of person who likes to learn about programming ideas several years before they hit the mainstream, it might be a good time to get curious about algebraic effects. Don’t feel like you have to though. It is a bit like thinking about async / await in 1999.

Okay, What Are Algebraic Effects?

The name might be a bit intimidating but the idea is simple. If you’re familiar with try / catch blocks, you’ll figure out algebraic effects very fast.

Let’s recap try / catch first. Say you have a function that throws. Maybe there’s a bunch of functions between it and the catch block:

function getName(user) {
let name = user.name;
if (name === null) {
throw new Error('A girl has no name');
return name;

function makeFriends(user1, user2) {
user1.friendNames.push(getName(user2));
user2.friendNames.push(getName(user1));

const arya = { name: null, friendNames: [] };
const gendry = { name: 'Gendry', friendNames: [] };
try {
makeFriends(arya, gendry);
} catch (err) {
console.log("Oops, that didn't work out: ", err);

We throw inside getName, but it “bubbles” up right through makeFriends to the closest catch block. This is an important property of try / catch. Things in the middle don’t need to concern themselves with error handling.

Unlike error codes in languages like C, with try / catch, you don’t have to manually pass errors through every intermediate layer in the fear of losing them. They get propagated automatically.

What Does This Have to Do With Algebraic Effects?

In the above example, once we hit an error, we can’t continue. When we end up in the catch block, there’s no way we can continue executing the original code.

We’re done. It’s too late. The best we can do is to recover from a failure and maybe somehow retry what we were doing, but we can’t magically “go back” to where we were, and do something different. But with algebraic effects, we can.

This is an example written in a hypothetical JavaScript dialect (let’s call it ES2025 just for kicks) that lets us recover from a missing user.name:

function getName(user) {
let name = user.name;
if (name === null) {
name = perform 'ask_name';
return name;

function makeFriends(user1, user2) {
user1.friendNames.push(getName(user2));
user2.friendNames.push(getName(user1));

const arya = { name: null, friendNames: [] };
const gendry = { name: 'Gendry', friendNames: [] };
try {
makeFriends(arya, gendry);
} handle (effect) {
if (effect === 'ask_name') {
resume with 'Arya Stark';

(I apologize to all readers from 2025 who search the web for “ES2025” and find this article. If algebraic effects are a part of JavaScript by then, I’d be happy to update it!)

Instead of throw, we use a hypothetical perform keyword. Similarly, instead of try / catch, we use a hypothetical try / handle. The exact syntax doesn’t matter here — I just came up with something to illustrate the idea.

So what’s happening? Let’s take a closer look.

Instead of throwing an error, we perform an effect. Just like we can throw any value, we can pass any value to perform. In this example, I’m passing a string, but it could be an object, or any other data type:

function getName(user) {
let name = user.name;
if (name === null) {
name = perform 'ask_name';
return name;

When we throw an error, the engine looks for the closest try / catch error handler up the call stack. Similarly, when we perform an effect, the engine would search for the closest try / handle effect handler up the call stack:

try {
makeFriends(arya, gendry);
} handle (effect) {
if (effect === 'ask_name') {
resume with 'Arya Stark';

This effect lets us decide how to handle the case where a name is missing. The novel part here (compared to exceptions) is the hypothetical resume with:

try {
makeFriends(arya, gendry);
} handle (effect) {
if (effect === 'ask_name') {
resume with 'Arya Stark';

This is the part you can’t do with try / catch. It lets us jump back to where we performed the effect, and pass something back to it from the handler. 🤯

function getName(user) {
let name = user.name;
if (name === null) {
// 1. We perform an effect here
name = perform 'ask_name';
// 4. ...and end up back here (name is now 'Arya Stark')
return name;

// ...

try {
makeFriends(arya, gendry);
} handle (effect) {
// 2. We jump to the handler (like try/catch)
if (effect === 'ask_name') {
// 3. However, we can resume with a value (unlike try/catch!)
resume with 'Arya Stark';

This takes a bit of time to get comfortable with, but it’s really not much different conceptually from a “resumable try / catch”.

Note, however, that algebraic effects are much more flexible than try / catch, and recoverable errors are just one of many possible use cases. I started with it only because I found it easiest to wrap my mind around it.

A Function Has No Color

Algebraic effects have interesting implications for asynchronous code.

[...]

Original source

📄 handlers-tutorial.pdf

📄 algeff-tr-2016-v2.pdf