I feel like Effect is today's Ramda. So cool but it's going to be regretted by you and people coming after you in few years.
Me and my team reverted to more stupid code and we are happier.
Nowadays I’d rather rely on libraries that don’t require a phd to use them properly.
This is 100% how to write more reliable software. We are in the process of reducing our TS dependencies to effectively just express and node-postgres and everything is becoming infinitely easier to manage.
I may simply be too dumb for lots of fancy functional programming. I can barely understand code when reading one line and statement at a time. Reading functions calling functions calling functions just makes me feel like gravity stopped working and I don't know which way is up. My brain too small.
I wouldn't use Effect for a lot of things. For some things, I'm very glad to have it. One thing Effect has going for it that Ramda didn't is that it's much less abstract and it's quite a bit more opinionated about some more complex concepts like error handling, concurrency, or scheduling.
Kind of like state machines. You shouldn't use them for everything. For some things, it's a bad idea not to (in my opinion).
Then of course subjectivity is a factor here. Some people will never like conventions like Effect, and that's fine too. Just write what feels right.
Having experience with ZIO / FP in Scala, I'm a bit biased in seeing the value of Effect systems as a whole, but taking on the burden of explaining that mental model to team members and future maintainers is a big cost for most teams.
Is 'retry / observability / error handling" something that comes from Effect?
Retrying[0], observability[1], and error handling[2] are first-class concerns and have built-in combinators to make dealing with those problems quite ergonomic. Having these features is a non-starter for any serious application, but unfortunately, the story around them in the TypeScript ecosystem is not great—at least as far as coherence goes. You often end up creating abstractions on top of unrelated libraries and trying to smash them together.
I'm a big fan of ReasonML / OCaml, and I think the future of TypeScript will involve imitating many of its code patterns.
[0] https://effect.website/docs/guides/error-management/retrying
[1] https://effect.website/docs/guides/observability/telemetry/t...
[2] https://effect.website/docs/guides/error-management/expected...
I liked the idea of Ramda until I saw code bases that where using it for everything.
I'm doing JS for over a decade now and I couldn't understand a thing.
It's the same effect as adding async code to Python or Rust, suddenly the entire team and the entire codebase (and often dependency choices) must adhere to it.
You can choose to make a single flow in your application an effect program. Or you can base most of your functions around it. It's really up to you how and where it's used. If you want to use an effect within non-effect code, that's easy to do, too.
You can think of effects like values. The value is obtained by executing the effect. Until it's called, the effect can be placed anywhere, in any function, in a generator, within promises, etc. Once you need its value, you execute it. It's compatible with most code bases as long as you can execute it to get the value. It's really up to the developer how portable they want their effects to be.
Passing Effects around will similarly infect the entire codebase, resulting in the entire dev team who interacts with it needing to buy in. Limiting the output of Effects to a single module owned by one zealot dev undermines having it around in the first place and it'll get removed and replaced as soon as that person leaves or gives up the fight.
Our team is full effect from two years and juniors can pick it and start working on it with ease.
For the love of god just use User / RegisteredUser / GuestUser and other abstractions that have some basis in the real world.
Solutions like effect are easier to appreciate as your application starts growing in complexity beyond simple todo apps.
Solutions like effect/schema are easier to appreciate as soon as you start needing complex types, encoding/decoding, branded types and more.
I am quite confident that effect will keep growing in popularity steadily and eventually grow.
It took more than 5/6 years for TypeScript or React to start getting spread around the JS community. Effect is here to stay and I'm confident it will eventually be adopted by plenty of developers.