Pondering Effects

Summary

Introduction Well I have some ramblings about algebraic effects I wanna record, but I don’t want to put them into a full blog post. I seem to have failed at that, so here we are, enjoy your gigantic schlob of text. This was triggered by this blog post and the replies on lobste.rs, which got me reading about effects in general and Effekt in particular. That said I don’t understand Effekt that well, so if I keep reading I might end up with more insights. Don’t take this as the end of the road, just a map of the parts I’ve wandered through so far. Last updated March 2026. WTF is an effect Effects happen when we want our programming language to have some metadata about functions (and data), and we want it to be sticky and inferrable. The easiest concrete example of this metadata is stuff like “can this function panic” or “does this function do I/O”, which are often useful questions to ask when you’re rummaging around in a big codebase. Usually these are questions you have to find the answer to the hard way, but like type inference, they are questions a compiler can answer for us if we give it some rules of how they work. Rust has a great example of effects in its unsafe annotation. If you have a function A that calls another function B, and B is unsafe, then A has to be unsafe as well. So unsafeness is “sticky”, it bubbles up the call chain – until in Rust at least, you use an unsafe block to suppress this. Rust’s const for compile-time evaluation is similar but is a bit of its own special case, and async is sort of an effect, so Rust people are apparently thinking of generalizing them.. So, if function B does I/O or allocates memory, and function A calls B, then A also does those things. So that gets us the name “effect”, we are talking about the side-effects that these functions have. Tracking and accounting for these side effects is sometimes useful for a compiler as well as for a human. Rust has two effects currently, unsafe and const, but from talking with people i...