Effect 4.0 Just Got a Lot Harder to Ignore

Author: Better Stack · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Effect 4.0 Just Got a Lot Harder to Ignore · Channel: Better Stack · 07:49 · Watch on YouTube

Topics: Software engineering with AI, AI developer tools

Summary

Effect makes failures and runtime requirements explicit in TypeScript function types, alongside their success values. Version 4.0 brings a rewritten runtime, a smaller bundle, higher reported throughput, consolidated packages, and renamed APIs. The video cautions that many performance figures are Effect’s own, and several modules remain unstable despite the stable 4.0 release. Effect may be worth trying for complex backend code, but adopting it deeply means building around its model rather than treating it as a small utility.

Key points

Effect’s type describes what a function returns, what errors it can produce, and what requirements it needs to run.
Handling an error removes it from the error type; adding a timeout introduces a possible timeout error.
Effect says version 4.0 was rebuilt from the ground up, including its fiber runtime.
The team reports a minimum bundle decrease from 35.5 KB in version 3 to about 7 KB in version 4, roughly 6.5 times higher task throughput, and lower memory use for 50,000 fibers.
Several packages, including Platform, RPC, and Cluster, have moved into the main Effect package, whose core has zero runtime dependencies.
API changes include Context Tag becoming Context Service, Catch All becoming Catch, Either becoming Result, and Runtime being removed.
Effect 4.0 is supported with bug fixes until September 2029, but AI, CLI, Cluster, HTTP, RPC, SQL, and other modules remain marked unstable.
The benchmarks have not been independently reproduced, and Effect’s own documentation gives slightly different minimum bundle figures.
The video recommends considering Effect for complex backend code, but cautions against partial adoption and calls out Schema and unstable modules as migration concerns.

Chapters

Start	Chapter	Summary
00:00	What Effect changes in TypeScript	The video introduces Effect and explains how its types make success values, failures, and runtime requirements explicit.
01:34	Errors, retries, and timeouts in practice	A get-user example shows how handling an error changes the error type and how adding a timeout introduces a possible timeout failure.
03:09	What’s new in Effect 4.0	The video covers the rewritten runtime, reported performance improvements, consolidated packages, API changes, and long-term support.
04:44	The trade-offs and caveats	The presenter compares Effect with separate tools, then cautions that benchmarks need independent testing and several modules remain unstable.
06:17	Migration and who should use Effect	The video discusses migration concerns and advises trying Effect for complex backend code while avoiding partial adoption in small apps.

Quotes

Success, error, requirements. — 01:02

I added a timeout. So the compiler added the possibility that the timeout can fail. — 02:37

almost every impressive number in this launch comes with an asterisk. — 05:15

Effect isn’t really a little utility you just drop into an existing codebase. — 06:47

how can this function fail. — 07:49

Concepts and entities

Effect, TypeScript, Effect 4.0, Zod, fp-ts, npm, Bun, Better Stack, Josh

Full transcript (original language)

00:00 Effect gets around 50 million downloads a week on npm. And somehow it’s still one of those Typescript libraries that’s weirdly hard to explain. Effect isn’t just error handling. It isn’t just retries, schemas, concurrency, or dependency injection either. It tries to pull all that into one system. And now version 4.0 is out with a rewritten runtime, a much smaller bundle, and a bunch of breaking changes. So I want to do two things. First, show you what effect actually changes when you write TypeScript. Then we’ll look at what’s

00:30 new in 4.0 and whether any of it is worth using. Okay, so the problem E effect is trying to solve is this. In normal TypeScript, this function returns a promise of a user and according to the type system, that’s basically it. But the real function has a lot more going on. The network could fail. The user might not even exist. That request can hang and TypeScript knows none of that. As far as your types are concerned, you get a user. As far as production is concerned,

01:02 well, good luck. Effect changes the contract. Instead of a promise of user, you get an effect containing three things. We get things like what comes back, what can go wrong, and what the code needs in order to run. Success, error, requirements. So now instead of failures being hidden somewhere inside the implementation, they become part of the functions type. If you enjoy coding tools that speed up your workflow, be sure to subscribe. We have videos coming out all the time. The important thing to note here is that the error type changes

01:34 as the code changes. If you handle not found, it disappears from the error channel. If you add a timeout, timeout error shows up. So the type is always describing what can actually happen at that point in the pipeline. This is effect 4.0 straight from npm with TypeScript 7 running on bun on my Mac. I have this get user function. It fetches a user and it has two custom errors not found and HTTP error. If I hover over it, what do we get? We get effect of

02:04 user. HTTP error or not found and never for the requirements. So before I even run this, the compiler knows exactly how this operation could fail. Now watch what happens when I start adding behavior. I’m going to drop this in here. I pipe it through an exponential retry three times. Then a two-cond timeout. Then I catch not found and return a fallback instead. Hover over it and look at the error type. Not found disappears

02:37 because I handled it. But now there’s a new failure. Timeout error. I added a timeout. So the compiler added the possibility that the timeout can fail. And that isn’t just some clever type trick. Let me drop the timeout to 50 milliseconds. And we’re going to run it. And there it is. Timeout error. Exactly the failure the type told us could happen. And once you understand that, effect starts to make a little bit more sense. So what did version 4 actually change here? Well, quite a lot of things. The team says effect was rebuilt

03:09 from the ground up. So what does that mean? That includes the fiber runtime underneath it. Basically the part responsible for scheduling all the work. And this is where some bigger numbers start appearing. They say the minimum bundle went from 35 1/2 kilobytes in version 3 to 7 kilobytes in version 4. That’s roughly 5 times smaller. Task throughput is about 6.5 times higher. And memory usage for 50,000 fibers supposedly dropped from roughly 157 megabytes to about 22. Those numbers do

03:41 sound great. Just hold on to them though cuz I need to touch on that again in a second. The second big change here is packaging. Effect used to be spread across multiple packages. Platform, RPC, cluster, and others now live inside the main effect package on one shared version number. And the core has zero runtime dependencies. So instead of managing a bunch of these effect packages and figuring out which versions work together, you now just have to install one package. Then there are the changes you’ll actually see in your

04:12 code. Context tag is now context service. Catch all is now just catch. Either became result and runtime is gone. There’s also something that’s key here if you’re trying to convince someone to actually use this, which is long-term support. Effect 4.0 gets bug fixes until September of 2029. And if you just want to try it, implementation is pretty darn straightforward. Bun add effect or yes, npm install effects. Now, at this point, some of you might say you

04:44 can just use ZOD for this. Add a retry library, add a timeout, and call it a day. And yeah, you can, but those tools don’t know about each other. Effect is trying to make typed errors, retries, timeouts, dependency injection, concurrency tracing, all this stuff a part of the same model. And as you compose those pieces together, the types keep following you. And effect has become big enough that it has even absorbed an old rival. FPTS officially merged into effect. Its own readme says

05:15 effect is basically what FPTS version 3 would have become. So all this is pretty cool except this is the point where I’d start being careful because almost every impressive number in this launch comes with an asterisk. Start with those benchmarks. They’re effects own numbers. they haven’t been independently reproduced and even effects own documentation doesn’t even completely agree. The launch blog says the minimal bundle is 7.1 kilobytes. The migration guide says about 6.3. That is a small

05:46 difference, but it’s a good reminder that this needs tested with more time. Then there’s those 50 million weekly downloads. That comes straight from npm. Last week around 29 million downloads were version 4. This does sound pretty big, right? That’s millions and millions except almost all of those were betas and release candidates. Stable 4.0 about 150,000 downloads on day one. That’s still quite a lot though. And then here’s the biggest catch. Version 4 is stable, but that does not mean everything inside version 4 is stable.

06:17 AI, CLI, cluster, HTTP, RPC, SQL are all still marked unstable and breaking changes can still launch in a minor release. The migration guide is very, very clear about this. Moving these modules into the main package did not stabilize them. Schema is probably the part I’d pay most attention to. It was heavily reworked during the beta and it has its own migration guide. Which brings us to actually upgrading. There’s no official code mod. The advice in the launch blog is basically give the

06:47 migration guide to your coding agent and honestly that will probably work just fine. And then we get to the complaint that has followed effect for years. that effect doesn’t just help with your app, it takes over your app. Effect isn’t really a little utility you just drop into an existing codebase. Once you adopt it deeply, you start writing your application around its model. It’s closer to switching languages, except the new language still happens to compile to the same JavaScript. For some, that’s the reason not to actually touch it. If you’re writing backend

07:18 TypeScript or aging code and your codebase is already full of retries, timeouts, and errors the type system can’t see, I think 4.0 is worth trying. If you’re already using effect 3, upgrade, but treat schema and the unstable modules like their own migration project. And if you’re building a small app that isn’t fully brought in the effect model yet, honestly, just skip it because effect is one of those tools where half adopting, it can actually be worse than never adopting it at all. It isn’t just the five times smaller bundle. It isn’t the

07:49 faster runtime and it isn’t 50 million npm downloads. Typescript can finally describe something it has mostly ignored. Not just what does this function return, but rather something along the lines of how can this function fail. I’m Josh from Better Stack. If you enjoy coding tips and tricks like this, be sure to subscribe. We’ll see you in another video.