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.
Yes, I read that and left scratching my head. Does it also encabulate?
Really reminded me of this classic pitch (and yes I know it's not the original turbo encabulator).
> More over, whenever fluorescent score motion is required it may also be employed in conjunction with a drawn reciprocation Dingle arm to reduce sinusoidal depleneration. The Retro Encabulator has now reached a high level of development and it's being successfully used in the operation of Millford Trunions. It's available soon wherever Rockwell Automation products are sold.
>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!
But that can't be a library? Must be a framework? (eg more batteries included)
Sometimes I use the wayback machine to visit marketing pages before the advent of AI, so I can get a better understanding of what they actually do instead of just a bunch of AI jargon.
part of it is because js is a throwing language, and since there are no "checked" exceptions they need to basically rebuild the universe in their paradigm.
but they seem to want to rebuild everything, eg
> The Console service exposes common console methods such as logging, warnings, errors, groups, counters, tables, and timers. Because console access goes through a service, programs can use custom console implementations in tests or other environments. This module also includes scoped helpers that close console groups or timers automatically.
Not playing devil's advocate or anything, but effect systems go beyond DI: it's not just about passing around a capability, but managing its lifecycle in a referentially transparent manner, i.e. monads all the way down. It's a real pain, but they set themselves up to bear the burden, so, good for the rest of us I guess?
Petty aside: Several JS people I know who were previously quite down on using a dependency injection framework are now seeing the benefits after adopting Effect. The most egregious example being a colleague who considered the adaption of DI tooling to be a language-level defect. It’s now one of his primary selling points for Effect.
i wouldn't consider the opinions of people who consider themselves "js people" to be particularly interesting, considering the ultimate state of that ecosystem. i say that as someone who writes js professionally.
you dont need an entire runtime to implement polymorphic console.logging. tbh the fact they want to implement the world to do this is more of an inditement against this approach than anything else
It isn't a case of wanting to implement the world to do this though.
Instead, it is a case of the active users of the library saying, "Wow, the Effect way of doing this is so much nicer, can we have everything this way please?"
The types allow you to very narrowly define functions so that you can, for example, require that a NonEmptyArray be passed. This helps to fulfill that requirement without casts.
As a Python person, that 2nd one looks like a bug. Expecting an exception there. Although also Python doesn't have an `undefined`; `None` would have to suffice.
Not really. If you try to take something from an empty container (language or real life) then you should get an error/issue. The container type doesn't change when it's empty, and the operation is just senseless; all that's happening here is added mental gymnastics that makes code unintuitive to read. Checking if/asserting a container isn't empty is a straight forward `if cont: ...` or `assert cont` in Python, which anyone can just get.
The type soft-enforces₁ it immediately for everyone though.
Without the type there are a few possibilities:
1. I could forget the assertion and have buggy code without realizing.
2. I could ensure that all uses do the assertion. Even if we can statically know that it is empty. This costs us the check for every call of the function, and ends up being more code.
Alternatively I could statically know in advance. The code won't let me `Array.pop` because that is invalid, so:
1. I *cannot* make that mistake
2. It cost no runtime performance
3. It cost no extra code in a function
1: I say soft-enforce because if someone were to pass a value incorrectly cast as NonEmpty, it would still have a runtime error, but that is a bug elsewhere, not here.
Right, you can attempt to take and potentially error, but if you already know that taking is possible you can skip the noise and simply return a result. Checking if your container is empty every time you remove an item is not free.
fiber/effects for UI and event bus, eg. OpenCode's opentui and harness are built on this library, been using the 4-beta whilst hacking on some OpenCode plugins
Almost every single JavaScript package is on NPM. Being on NPM does not automatically increase your attack vectors. The vast majority of the npm attacks have been "Supply Chain Attacks"[0] where an upstream dependency is injected with malicious code, then automatically downloaded and executed when users update a package.
If you look at Effect's package.json on GitHub[1], you'll see that they have several "devDependencies", but no regular "dependencies". That means, unless you are working on the package itself, using it does not require downloading any other packages whatsoever. Thus, Effect is not susceptible to any of the issues that you have read about in the news. The only way malicious code could be transported through the package would be if the maintainers suddenly became evil.
That being said, I don't use Effect and I think it's kind of overrated by the FP community. But, I appreciate the ideas behind it, and I felt the need to educate you about your needless fear of any library simply existing on NPM.
Can someone explain why this is a good idea? There is a ton of magic here, since the value string is not even part of the UserName function signature. Dependency injection is not about hiding your dependencies. On a first look, this seems to be really bad, but I might be totally misunderstanding this library.
import { make, useAtomValue } from "@effect/atom-react"
import { Atom } from "effect/reactivity"
import * as React from "react"
import { renderToStaticMarkup } from "react-dom/server"
const User = make((name: string) => Atom.make(name))
function UserName() {
const atom = User.use()
const value = useAtomValue(atom)
return React.createElement("span", null, value)
}
export function App() {
return React.createElement(
User.Provider,
{ value: "Ada" },
React.createElement(UserName)
)
}
renderToStaticMarkup(React.createElement(App)) // => "<span>Ada</span>"
The atom-react module is for interacting with React, and ScopedAtom is for scoping those interactions to specific subtrees, so the entire purpose of this particular example is to avoid passing state through many nested functions. Here's the equivalent React code without Effect:
import { createContext, useContext, useState } from "react";
import { renderToStaticMarkup } from "react-dom/server";
const UserContext = createContext(null);
function UserProvider({ value, children }) {
const [name] = useState(value);
return <UserContext.Provider value={name}>{children}</UserContext.Provider>;
}
function UserName() {
return <span>{useContext(UserContext)}</span>;
}
function App() {
return (
<UserProvider value="Ada">
<UserName />
</UserProvider>
);
}
renderToStaticMarkup(<App />); // => "<span>Ada</span>"
Ah thx, this is a rewrite of React's Context. `userName` would have been so much better than `value`. I had to keep the possibility in mind that `value` is a kind of implicit magic variable in atoms.
Not sure what benefit this atom stuff brings. In react I can see that `value` is an argument, which from an fp point of view is a clear pro.
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.
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?
I was skeptical but have come to find it indispensable. I absolutely love it for exhaustive handling of states and corresponding typed errors, schemas, and managing concurrency. It’s possible with other tools, but Effect offers much more than just that. It’s a lot of fun. There’s a learning curve, but once it clicks it’s pretty intuitive. It’s simpler than it looks.
It has truly led to shipping more robust programs that are easier to debug. I don’t use it everywhere, but I don’t think twice with larger backend projects.
Rx anything is an absolute nope for me after living in Rx hell for several years. It ruins error handling and stack traces and everything becomes an observable callback
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.
Absolutely you can. Every Effect program has to be run via some call to a ‘runX()’ function that accepts your Effect program. And the call-site where you run it is the boundary of your Effect program so you can make your app as much or as little Effect as you want.
Thinking of it abstractly, Effects is a more generic version of the "what color is your function"¹ dilemma, and the way to make this kind of abstraction not "color too much" (i.e. not pollute the core language by wrapping everything in a monad that implements its own parallel runtime with exceptions, asynchrony, …) is an active research topic². Scala is advancing in this area by scoping effects in a manner that's not too dissimilar to a generalized version of rust's borrow-checker, and I'm very curious to see how that spans out.
I’ve been using the beta on three separate projects for quite a while now and it has been totally pain-free. I mostly use the v3x core library (which has expanded to contain other libraries in v4) and Schema so I can’t speak to much outside of those, but I trust they’ve done a great job all around.
I don’t see it mentioned here, but 4 also comes with a much simpler API in some modules. Schema is much better. It’s an exceptional update. I followed many of the video logs on YouTube and was impressed by the team. This is one of my favourite software projects, period. This rebuild is incredibly well done, and I hope a lot of people are willing to try it out and adopt it, especially with the LTS.
This was me in the past too. But Effect's DI is only advantages, because it is all type safe, including that you _must_ provision the dependency. The result is all the benefits of prop-drilling (explicit) without its problems (now your whole execution tree must learn about this dependency in a leaf).
Effect's type-safe DI simplifies application architecture (you now have a clear algebra that is interfaces + layer composition), promotes important architecture principles (e.g. it's a lot easier to compose within the application when components are not tangled because they have to pass "ambient" service props through), and as a result apps are a lot easier to maintain and evolve.
This is the sort of guardrail that really matters in the age of AI, because AI can still mess things up, but the blast radius of messing things up locally is very different than sloppifying architecture—and makes the problem of slop itself more treatable.
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.
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.
I guess I'm old, and there's a lot of grey in my beard but... whatever happened to just, you know, writing code?
Simple code. Nothing clever, just logic and clear expression of what needs to be done.
It's so pleasant to just write code that does things.
Code that you can put a breakpoint on to debug.
Code that doesn't go through a library abstraction, a framework, a philosophy, three AI agents, a complex type system, metaprogramming and a cross compiler to run.
I understand that maintainable code needs organization, but I think we go off the rails when the systems of organization dominate the work, and the actual execution logic seems secondary.
I see so many teams spend endless cycles debating theories of frameworks, fp vs oop, type systems, AI rigs, etc..., and barely any time at all on solving the actual problem.
To me Effect is past those endless cycles and debates. It leaves you in control, and doesn't take over, but it gives you primitives that are really needed. Primitives without which you can get by, but you end up paying in correctness, future issues, and reinventing the wheel to solve the problem (often incorrectly). In the JS world, this is one of the reasons we end up with hundreds of dependencies for a small project: besides the actual abstractions, you have all the plumbing between abstractions.
Effect solves this elegantly.
> barely any time at all on solving the actual problem
This is how we should measure things TBH. For me, Effect solves very real problems. As a Principal engineer, I sleep so much better overseeing many teams and agents releasing to production because of Effect.
> Code that you can put a breakpoint on to debug.
This is a pain point for sure. For me, the tradeoff is clearly positive (because also the need for debugging that way decreases significantly with more declarative, type-safe, well-architected, telemetry-first code), but it is still very unfortunate.
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.
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.
I had the same thought, until I realized the posted link is for their 4.0 release rather than their homepage.
Their main page makes the product pretty clear.
https://effect.website
Still can’t tell if it’s a language, library or framework
Have you tried reading the big bold text at the top of the page?
> Reliable TypeScript for the AI era
It is a library.
I'm with the sibling. A library for what? UI, backend, graphing, visual effects? What does this replace?
A library for effects. Algebraic effects, to be more precise.
To be fair "algebraic effects" is part of my priors. If you don't know what that is those specific words won't help you, but the examples should!
"typed error handling, structured concurrency, resource safety, and observability, all from one composable core"
Yes, I read that and left scratching my head. Does it also encabulate?
Really reminded me of this classic pitch (and yes I know it's not the original turbo encabulator).
> More over, whenever fluorescent score motion is required it may also be employed in conjunction with a drawn reciprocation Dingle arm to reduce sinusoidal depleneration. The Retro Encabulator has now reached a high level of development and it's being successfully used in the operation of Millford Trunions. It's available soon wherever Rockwell Automation products are sold.
Not understanding something is different from it having no meaning.
Absolutely, but there's so little context offered to derive actual meaning. If you already know, it's probably a lot easier.
And if multiple people are wondering what something fundamentally is, perhaps it's the pitch, not the people.
>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!
But that can't be a library? Must be a framework? (eg more batteries included)
> (eg more batteries included)
That's not the definition of a framework.
You call a library. A framework calls you.
You forgot the /s
Does it, though?
I can't parse this into meaning anything:
"Reliable TypeScript for the AI era
Build production-ready systems your team can ship, customers can depend on, and AI agents can work with."
OK, it's written in TypeScript, I guess. Is it a library? What does it do?
I’ve had to click around a bit and I think this is a better summary: https://effect.website/docs/v4/getting-started/why-effect#th...
This seems to be similar in spirit to railway oriented programming (see e.g. https://returns.readthedocs.io/en/latest/pages/railway.html), but I’m not 100% confident here.Monad Maybe?
Kinda like that, but with the error branch having a value too. I think Result is the common name for this monad:
https://en.wikipedia.org/wiki/Result_type[dead]
Sometimes I use the wayback machine to visit marketing pages before the advent of AI, so I can get a better understanding of what they actually do instead of just a bunch of AI jargon.
It is very AI friendy - has the painful AI generated corpo-speak all over most of its docs: bla-blah is XXX, not YYY, painfully-repeated ad-nauseam.
Anyways, I understood it as a Typescript copy of Scala's ZIO library.
it's for people who want to write ocaml or rust, but in typescript for some reason
It does seem like they're boiling the ocean, for... whatever reason programmers do these things.
Rebuild JS's core data structures: https://effect.website/docs/v4/api/effect/Array
Then rebuild the entire JS ecosystem on top of their custom data structures.
And then the main heading on their home page is "Reliable TypeScript for the AI era"? Really? I'll pass.
part of it is because js is a throwing language, and since there are no "checked" exceptions they need to basically rebuild the universe in their paradigm.
but they seem to want to rebuild everything, eg
> The Console service exposes common console methods such as logging, warnings, errors, groups, counters, tables, and timers. Because console access goes through a service, programs can use custom console implementations in tests or other environments. This module also includes scoped helpers that close console groups or timers automatically.
yeah idk mate
Console is the very core of what I expect an effect system to need to reimplement.
Console is IO and IO is the effect.
just use a dependency injected logger then...
Not playing devil's advocate or anything, but effect systems go beyond DI: it's not just about passing around a capability, but managing its lifecycle in a referentially transparent manner, i.e. monads all the way down. It's a real pain, but they set themselves up to bear the burden, so, good for the rest of us I guess?
This is super useful though. It allows you to swap out implementations for things like logging and monitoring. Not sure what the confusion is here.
Petty aside: Several JS people I know who were previously quite down on using a dependency injection framework are now seeing the benefits after adopting Effect. The most egregious example being a colleague who considered the adaption of DI tooling to be a language-level defect. It’s now one of his primary selling points for Effect.
i wouldn't consider the opinions of people who consider themselves "js people" to be particularly interesting, considering the ultimate state of that ecosystem. i say that as someone who writes js professionally.
you dont need an entire runtime to implement polymorphic console.logging. tbh the fact they want to implement the world to do this is more of an inditement against this approach than anything else
It isn't a case of wanting to implement the world to do this though.
Instead, it is a case of the active users of the library saying, "Wow, the Effect way of doing this is so much nicer, can we have everything this way please?"
It literally says:
> Works with JavaScript arrays
Yes but why? Why should I import a giant dependency to do this:
instead of using what's built in to the language?You wouldn't. Effect isn't an array library.
did you read the docs? it says
"Use when you need to guarantee a non-empty result after adding a required trailing value."
...whatever that means lol
The types allow you to very narrowly define functions so that you can, for example, require that a NonEmptyArray be passed. This helps to fulfill that requirement without casts.
NonEmpty is a type that allows you to distinguish between:
As a Python person, that 2nd one looks like a bug. Expecting an exception there. Although also Python doesn't have an `undefined`; `None` would have to suffice.
That 2nd one being a bug is exactly what the type system and NonEmpty types is designed to help prevent.
Not really. If you try to take something from an empty container (language or real life) then you should get an error/issue. The container type doesn't change when it's empty, and the operation is just senseless; all that's happening here is added mental gymnastics that makes code unintuitive to read. Checking if/asserting a container isn't empty is a straight forward `if cont: ...` or `assert cont` in Python, which anyone can just get.
The type soft-enforces₁ it immediately for everyone though.
Without the type there are a few possibilities: 1. I could forget the assertion and have buggy code without realizing. 2. I could ensure that all uses do the assertion. Even if we can statically know that it is empty. This costs us the check for every call of the function, and ends up being more code.
Alternatively I could statically know in advance. The code won't let me `Array.pop` because that is invalid, so:
1: I say soft-enforce because if someone were to pass a value incorrectly cast as NonEmpty, it would still have a runtime error, but that is a bug elsewhere, not here.Right, you can attempt to take and potentially error, but if you already know that taking is possible you can skip the noise and simply return a result. Checking if your container is empty every time you remove an item is not free.
Not only that but the play tab is broken. The default example does not compile in their own playground. And I'm still not sure what this thing is.
It’s got electrolytes.
fiber/effects for UI and event bus, eg. OpenCode's opentui and harness are built on this library, been using the 4-beta whilst hacking on some OpenCode plugins
[dead]
[dead]
[dead]
It's made with Npm, which makes me wonder if it's really safe ...
But I only read the news when it comes to npm, so maybe my fear is not justified.
Almost every single JavaScript package is on NPM. Being on NPM does not automatically increase your attack vectors. The vast majority of the npm attacks have been "Supply Chain Attacks"[0] where an upstream dependency is injected with malicious code, then automatically downloaded and executed when users update a package.
If you look at Effect's package.json on GitHub[1], you'll see that they have several "devDependencies", but no regular "dependencies". That means, unless you are working on the package itself, using it does not require downloading any other packages whatsoever. Thus, Effect is not susceptible to any of the issues that you have read about in the news. The only way malicious code could be transported through the package would be if the maintainers suddenly became evil.
That being said, I don't use Effect and I think it's kind of overrated by the FP community. But, I appreciate the ideas behind it, and I felt the need to educate you about your needless fear of any library simply existing on NPM.
[0] https://unit42.paloaltonetworks.com/monitoring-npm-supply-ch...
[1] https://github.com/Effect-TS/effect/blob/main/package.json
What do you mean by "made with npm"?
Uses npm for package management.
Can someone explain why this is a good idea? There is a ton of magic here, since the value string is not even part of the UserName function signature. Dependency injection is not about hiding your dependencies. On a first look, this seems to be really bad, but I might be totally misunderstanding this library.
(src = https://effect.website/docs/v4/api/atom-react/ScopedAtom)The atom-react module is for interacting with React, and ScopedAtom is for scoping those interactions to specific subtrees, so the entire purpose of this particular example is to avoid passing state through many nested functions. Here's the equivalent React code without Effect:
Ah thx, this is a rewrite of React's Context. `userName` would have been so much better than `value`. I had to keep the possibility in mind that `value` is a kind of implicit magic variable in atoms.
Not sure what benefit this atom stuff brings. In react I can see that `value` is an argument, which from an fp point of view is a clear pro.
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
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?
I was skeptical but have come to find it indispensable. I absolutely love it for exhaustive handling of states and corresponding typed errors, schemas, and managing concurrency. It’s possible with other tools, but Effect offers much more than just that. It’s a lot of fun. There’s a learning curve, but once it clicks it’s pretty intuitive. It’s simpler than it looks.
It has truly led to shipping more robust programs that are easier to debug. I don’t use it everywhere, but I don’t think twice with larger backend projects.
Rx anything is an absolute nope for me after living in Rx hell for several years. It ruins error handling and stack traces and everything becomes an observable callback
Try it out! Translate a few of the privatives and then see what happens when you try composing a few different ones.
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.
Absolutely you can. Every Effect program has to be run via some call to a ‘runX()’ function that accepts your Effect program. And the call-site where you run it is the boundary of your Effect program so you can make your app as much or as little Effect as you want.
Thinking of it abstractly, Effects is a more generic version of the "what color is your function"¹ dilemma, and the way to make this kind of abstraction not "color too much" (i.e. not pollute the core language by wrapping everything in a monad that implements its own parallel runtime with exceptions, asynchrony, …) is an active research topic². Scala is advancing in this area by scoping effects in a manner that's not too dissimilar to a generalized version of rust's borrow-checker, and I'm very curious to see how that spans out.
¹: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
²: https://www.scala-lang.org/api/3.5.0/docs/docs/reference/exp...
I’ve been using the beta on three separate projects for quite a while now and it has been totally pain-free. I mostly use the v3x core library (which has expanded to contain other libraries in v4) and Schema so I can’t speak to much outside of those, but I trust they’ve done a great job all around.
I don’t see it mentioned here, but 4 also comes with a much simpler API in some modules. Schema is much better. It’s an exceptional update. I followed many of the video logs on YouTube and was impressed by the team. This is one of my favourite software projects, period. This rebuild is incredibly well done, and I hope a lot of people are willing to try it out and adopt it, especially with the LTS.
Effect looks so cool, but the only thing that is off-putting (for me) is the DI. I don't even mind the syntax.
I just don't like these DI systems that pull stuff "out of thin air" auto-magically instead of just passing arguments.
This was me in the past too. But Effect's DI is only advantages, because it is all type safe, including that you _must_ provision the dependency. The result is all the benefits of prop-drilling (explicit) without its problems (now your whole execution tree must learn about this dependency in a leaf).
Effect's type-safe DI simplifies application architecture (you now have a clear algebra that is interfaces + layer composition), promotes important architecture principles (e.g. it's a lot easier to compose within the application when components are not tangled because they have to pass "ambient" service props through), and as a result apps are a lot easier to maintain and evolve.
This is the sort of guardrail that really matters in the age of AI, because AI can still mess things up, but the blast radius of messing things up locally is very different than sloppifying architecture—and makes the problem of slop itself more treatable.
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.
Is this like a spring boot for typescript or something like that? Looks kind of interesting
It's like Scala and Spring Boot had a baby and the baby was in typescript. Super solid project great engineers.
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.
Why not pick Scala (-native), or OCaml, or…
I guess I'm old, and there's a lot of grey in my beard but... whatever happened to just, you know, writing code?
Simple code. Nothing clever, just logic and clear expression of what needs to be done.
It's so pleasant to just write code that does things.
Code that you can put a breakpoint on to debug.
Code that doesn't go through a library abstraction, a framework, a philosophy, three AI agents, a complex type system, metaprogramming and a cross compiler to run.
I understand that maintainable code needs organization, but I think we go off the rails when the systems of organization dominate the work, and the actual execution logic seems secondary.
I see so many teams spend endless cycles debating theories of frameworks, fp vs oop, type systems, AI rigs, etc..., and barely any time at all on solving the actual problem.
To me Effect is past those endless cycles and debates. It leaves you in control, and doesn't take over, but it gives you primitives that are really needed. Primitives without which you can get by, but you end up paying in correctness, future issues, and reinventing the wheel to solve the problem (often incorrectly). In the JS world, this is one of the reasons we end up with hundreds of dependencies for a small project: besides the actual abstractions, you have all the plumbing between abstractions.
Effect solves this elegantly.
> barely any time at all on solving the actual problem
This is how we should measure things TBH. For me, Effect solves very real problems. As a Principal engineer, I sleep so much better overseeing many teams and agents releasing to production because of Effect.
> Code that you can put a breakpoint on to debug.
This is a pain point for sure. For me, the tradeoff is clearly positive (because also the need for debugging that way decreases significantly with more declarative, type-safe, well-architected, telemetry-first code), but it is still very unfortunate.
[flagged]