alt Hacker NewsEverything he lists is solved by effect-ts [1] bar, obviously, the language support (effect has its own fiber-based runtime like ZIO's scala).
I've been using it for 5+ years and my 4 men team can scale to supporting 6 different products (each running millions $ in business, sometimes daily), as we reuse the same patterns and architecture. This would not be possible without Effect, even though I'm lucky to have terrific engineers as colleagues, we just wouldn't be able to without the endless goodies from Effect.
The amount of features is basically endless, as effects and runtimes weren't enough, from SQL to AI, from effectful schemas (encoders/decoders), first-class OTEL support, CLI, debuggers, editor extensions, and many others. There's still countless modules I have yet to see or use.
Runtimes are available for each platform, including cloudflare workers.
There's absolutely nothing in TypeScript land to have such a wide scope.
v4 will also bring durable workflows (I'm already using v4 beta and that feature in prod) and many other goodies. That's quite important for us needing to have procedures that need to survive redeploys, crashes, etc.
I would never go back to writing standard TypeScript.
There is a learning curve, but you can adopt it incrementally. Nobody adopting it has ever gone back.
That being said, it would be great if there was a proper effect-based language (I've seen few projects like Effekt, but there's way too many things missing) as TypeScript is verbose, and effect adds its own verbosity.
Replies
When I started a typescript server project, I spent quite some time - setting up dependency injection framework to pass context (tsyringe) - finding a good schema validation library (zod) - use neverthrow for typed error. - wrote a few withSpan, recordDuration OTEL helper functions.
Then I heard about Effect-ts, checked the doc, and realize that Effect-ts already has all these things, in a single package.
IMO Effect-ts is currently the most practical effect system right now. While it does not support resuming like in other algebraic effect languages, it is powerful enough to express common patters, but not too powerful so that the code becomes hard to understand.
I hope effect-ts gets more traction. The biggest obstacle to sell it right now is that the API doc is not great. I had to trace the source code several times just to see how a type is defined. I hope Effect-ts team is aware that more people will use it if it has a proper documentation.
The learning curve is quite steep but once you get it you become effect pilled. You can completely separate the WHAT the application does from HOW it will do it.
[dead]
Effect is pretty nice, I'm not sure how worth it it is for the frontend, but I've heard good things on the backend, but sadly I don't use TypeScript for backend work, mainly Rust, and would love to see something like that there. I'm not sure how much Rust's type system would make it possible though however.
I know parts of Effect like its schema are incrementally adoptable but if you use it substantially with many of its features, isn't it viral in a sense? In that you need to do things the Effect way and wrap libraries into Effect functions?