Effect 4.0

claude-ai

Three clicks, no info what effect 4.0 is, except that it's AI-ready, safe, good, and re-built from the ground up. No idea what it actually is.

ruby14

It’s wild how easy it is to build robust systems with Effect. I’m working on a little social media web app and it has been so incredibly simple to build the API and a background worker process with Effect. I get logging, telemetry, error handling, concurrency, API doc generation, and more for free! I think this library gets somewhat maligned for being complex, which I don’t think is fair for how much it offers given how much more complex a an equivalent solution would be without Effect. With v4, I also don’t feel like I am even having to wrestle with TypeScript’s type system at all. I define some basic interfaces for my services and schemas for my data models and everything is just inferred through usage for the most part. It honestly starts to feel like I’m writing JavaScript for the most part. This library gets lots of comparisons to functional programming languages/libraries, which is fair, but I think someone working in .NET/C# would be feel right at home.

2001zhaozhao

Is this like a spring boot for typescript or something like that? Looks kind of interesting

sibeliuss

It is hard to understand why one would want to introduce this into their codebase given how functional javascript is right away. It lives in the spectrum of rxjs - super powerful, but is it necessary? Can all of those concepts be distilled down into what you would use on the day to day (just a few), with less concept density, and just as much functional goodness?

jauntywundrkind

I can't wait for Rust to someday have something even part way as clear at composing systems. Eventually I really hope we see programming languages that lean back in to what Erlang started more. This is a leap, but imo having inbuilt great patterns for system design would look a whole lot like Effect! Systems practically assemble themselves. There's great powerful meaningful abstractions under foot. The only other meaningful effort I can call out is Clojure, which made a handful of good primitives. That community only really used atoms and defs, less refs (software transactional memory) and agents, is what I've been told.

chrysoprace

Is there a way to implement Effect without it becoming a leaky abstraction that takes over your whole app? Presumably you'd have to create an entire abstraction layer with strict boundaries, such as nestjs does with RxJS Observables, but even that has problems with leaking Observables when you need to hook into the framework's lifecycle.

kiliancs

Effect is to TypeScript what TypeScript is to Effect. It just pays off. But most of the learning curve or the unfamiliarity with syntax and even concepts goes away with AI. In fact, the same reasons why it makes it good for teams makes it good for AI. When a team member or an agent use the Effect patterns, I know I there is a lot less they could have messed up. One issue with Effect is that it's hard to intro because it does many things. But it does them well, and it does all of them because only a coherent system can deliver the promise of allowing you to write production-ready TypeScript. I'll list some things: - Effects: how you describe programs. For some people it helps to think of them as promises on steroids. In addition to tracking the return type, they track the types of errors it could fail with, as well as its dependencies (see context/layers). - Fibers: primitives for concurrency—but most of the time you don't have to think about them because the `Effect` methods handle most common scenarios - Context/Layers: type-safe dependency injection. Have your cake and eat it too. You define context interfaces, use them within effects, and TypeScript forces you provide implementations of those interfaces via layers. Layers can provide more than one context, and can also depend on other layers. Very powerful. - Schema: think Zod, but with the concept of codecs (to be fair Zod has this too), which means you define how things encode (e.g. what API takes and responds with) and decode (e.g. what my app works with). I love `Model`, which derives schemas for the API side and repo (db) side, so I can define a domain model declaratively with things like "account number should be replaced with * except the last 4 digits in the API; it should be Redacted (wrapped, can't leak to logs etc) within the app logic, and should be encrypted in the database". - Standard library: lots of things that should standard in JS/TS and aren't, or exist but are not coherent or play well together. When I don't use Effect, I have to choose between doing things well or shipping (and suffering the consequences). And I don't mean just strings, dates, decimals. I mean also queues, cache, etc. - SQL primitives to work with transactions, migrations, queries. There are interfaces on top of this for popular ORMs. - HTTP server; and ways to define your API with types and schemas, then implement it. - Telemetry, logging by default ...and I could go on. I am not looking back.

artisin

I was (still am) a huge fan of fp-ts [1], which, in effect , was rolled into the Effect-TS ecosystem. And I'm still bummed TS+ [2] didn't work out, because I've never managed to love Effect-TS the way I loved fp-ts. Maybe it's the lack of tacit function calling, the conventions, AI/modern-marketing push, or simply the daunting scope and scale (even more so with v4). Still, despite my gripes, if you're willing to spend the time and effort, it's the safest and most elegant way to write TypeScript. Plus, it's now dependency-free, and the increasingly good LSP/editor support removes a lot of the friction that used to come with completions and diagnostics. [1] https://github.com/gcanti/fp-ts [2] https://effect.website/blog/ts-plus-postmortem