40 ms·

I love Zod, but recently I've been converting to Effect's Data and Schema modules. Previously I liked a combination of Zod and ts-pattern to create safe, patte

I love Zod, but recently I've been converting to Effect's Data and Schema modules. Previously I liked a combination of Zod and ts-pattern to create safe, pattern matching-oriented logic around my data. I find Effect is designed far better for this, so far. I'm enjoying it a lot. The Schema module has a nice convention for expressing validators, and it's very composable and flexible: https://effect.website/docs/guides/schema/introduction https://effect.website/docs/guides/schema/introduction There are also really nice aspects like the interoperability between Schema and Data, allowing you to safely parse data from outside your application boundary then perform safe operations like exhaustively matching on tagged types (essentially discriminated unions): https://effect.website/docs/other/data-types/data#is-and-match https://effect.website/docs/other/data-types/data#is-and-mat... It feels extremely productive and intuitive once you get the hang of it. I didn't expect to like it so much. I think the real power here is that these modules also have full interop with the rest of Effect. Effects are like little lazy loaded logical bits that are all consistent in how they resolve, making it trivial to compose and execute logic. Data and Schema fit into the ecosystem perfectly, making it really easy to compose very resilient, scalable, reliable data pipelines for example. I'm a convert. Zod is awesome if you don't want to adopt Effect wholesale, though.

bjacobso 2y ago
I've had a very similar experience, and have been slowly moving from zod and ts-rest to @effect/schema and @effect/platform/HttpApi as well as migration to Effect Match from ts-pattern. There is a learning curve but its a pretty incredible ecosystem once you are in it for a bit. I think the real turning point was typescript 5.5 (May 2024). The creator of typescript personally fixed a bug that unlocked a more natural generator syntax for Effect, which I think unlocks mainstream adoption potential. https://twitter.com/MichaelArnaldi/status/1785061608894451725 https://twitter.com/MichaelArnaldi/status/178506160889445172... https://github.com/microsoft/TypeScript/pull/58337 https://github.com/microsoft/TypeScript/pull/58337
- morbicer 2y ago
  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.
  - bjacobso 2y ago
    that is certainly a possibility
  - steve_adams_86 2y ago
    I agree in some contexts. Kind of like Rust, I see a place for more durable code that's harder to reason about in some cases. 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.
  - k__ 2y ago
    Yes it's quite sad. 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.
  - Stoids 2y ago
    I think going all-in on Effect in its current state is not something I'd do. However there's a subset of its functionality that I'm currently replicating with a bunch of different libraries: ts-pattern, zod, some lightweight result / option wrapper like ts-belt, etc. Pretty much trying to pretend I'm writing ML / OCaml. Having those all in one package is quite convenient. Add in TypeScript's the much needed story around retry / observability / error handling—I see why people lean into it. 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.
- steve_adams_86 2y ago
  I agree about the turning point. Things have improved dramatically. And I know it probably doesn't feel the same for tons of people, but I love to see generators being used in every day code. The learning curve just about turned me away from it at the start, but I'm glad I stuck with it. I think learning Effect would actually teach a lot of people some very useful concepts and patterns for programming in general. It's very well thought out.
- dimal 2y ago
  How did you find learning Effect? The sales pitch sounds great, but when I went through the docs it seemed pretty confusing to me. I’m sure there are reasons for the everything but I couldn’t grok it. In particular, I’m thinking of the Express integration example.[0] I look at that and think, I need all that just to create a server and a route? What’s the benefit there? I’m hesitant to buy into the ecosystem after looking at that. I want to like it, though. [0] https://effect.website/docs/integrations/express https://effect.website/docs/integrations/express
  - theschwa 2y ago
    Yeah, looking at that example feels like jumping straight into the deep end of the pool. I think it helps going through a tutorial that breaks down the why of each piece. I really liked this tutorial on it: https://www.typeonce.dev/course/effect-beginners-complete-getting-started https://www.typeonce.dev/course/effect-beginners-complete-ge... Some core things from Effect though that you can see in that Express example: * Break things down into Services. Effect handles dependency injection, that's typed, for services so you can easily test them and have different versions running for testing, production, etc. * Fibers for threaded execution * Managing resources to make sure they're properly closed with scope I think a lot of these things though often aren't truly appreciated until you've had something go wrong before or you've had to build a system to manage them yourself. *
    - dimal 2y ago
      Yeah, this looks like the tutorial I needed. Thanks.
    - mewpmewp2 2y ago
      But I feel like I've worked with massive systems with a lot going on where nothing has gone wrong that this sort of thing specifically would solve it. I think it would just increase learning curve and make people make other types of mistakes (business logic or otherwise) because it's so much less readable and understandable. I've seen similar libraries used in the past that have caused much more worse bugs because people misunderstand how they exactly work.
Aeolun 2y ago
I like the functionality, but the verbosity of the API makes me want to immediately ignore it. I feel like zod nailed the usability part.
- epolanski 2y ago
  Schema is a much powerful tool than Zod. Zod is merely a parser, while Schema has a decoder/encoder architecture.
seer 2y ago
I’d love to hear more stories of people using Effect in production codebases. It looks very similar in its ideas to fp-ts (in the “let’s bring monads, algebraic types etc to typescript” sense). But I did hear from teams that embraced fp-ts that things kinda ground to a halt for them. And those were category theory enthusiasts that were very good scala devs so I’m sure they knew what they were doing with fp-ts. What happened was that the typescript compile time just shot into minutes, for a moderately sized micro-service, without anything externally heavy being introduced like you could on the frontend. It just turned out that Typescript compiler was not so great at tracking all the inferred types throughout the codebase. So wonder if things have improved or effect uses types more intelligently so that this is not an issue.
- golergka 2y ago
  > It looks very similar in its ideas to fp-ts (in the “let’s bring monads, algebraic types etc to typescript” sense). It's the next version of fp-ts, developed by the same people, AFAIK
skrebbel 2y ago
Like Java, you can write Haskell in any language but that doesn't mean it's always a good idea.
- MichaelArnaldi 2y ago
  Which is why our principle with Effect is NOT to port Haskell. For example we don't use Typeclasses which are big in haskell, we lean heavily on variance which is not in Haskell. It's an ecosystem though to write production-grade TypeScript, not Haskell in TypeScript
williamcotton 2y ago
Why not write your code in F# and compile it to TypeScript using Fable [1]? This way you can use native language features for discriminated unions, functional pipelines, and exhaustive pattern matching to model your domain instead of shoe-horning such functionality into a non-ML language! Model your domain in F#, consume it in Python or C# backends and TypeScript frontends. The downside is needing to know all of these languages and run times but I think I'd rather know F# and the quirks with interacting with TypeScript than a library like Effect! [1] https://fable.io https://fable.io
- steve_adams_86 2y ago
  This is so cool! I’ll have to try it out soon. Thanks!
- MichaelArnaldi 2y ago
  https://effect.website/docs/other/myths#effect-should-be-a-language-or-use-a-different-language https://effect.website/docs/other/myths#effect-should-be-a-l...
- IshKebab 2y ago
  I've tried compile-to-JS languages before but their big weaknesses are: 1. Debugging can become quite a pain. Nobody likes debugging generated code. 2. You don't get to use libraries and tools from the enormous JavaScript ecosystem. 3. Eventually you'll find some web feature that they haven't wrapped in your language and then you're in for FFI pain. In the end I found Typescript was good enough that it wasn't worth dealing with those issues.
  - deleted 2y ago
    [deleted]
  - williamcotton 2y ago
    Fable is still very much integrated with the runtime so there’s an expectation to handle those bullet points with inline annotations. You can build an entire application in F# and compile to JS but another option is compiling to TS and calling that F# code from your TS app. I/O and views and whatnot are written in TS and the domain model is in F#. The entire model could be nothing but pure functions and resolve to a single expression!
aswerty 2y ago
Effect reminds me more of something like NestJS - essentially an end to end application framework that takes over your whole application. Rather disappoint to see something like this being plugged as an alternative to something like zod which is a nice library that stays in its corner and has a nice fixed scope to it's functionality.

bjacobso 2y ago

I've had a very similar experience, and have been slowly moving from zod and ts-rest to @effect/schema and @effect/platform/HttpApi as well as migration to Effect Match from ts-pattern. There is a learning curve but its a pretty incredible ecosystem once you are in it for a bit. I think the real turning point was typescript 5.5 (May 2024). The creator of typescript personally fixed a bug that unlocked a more natural generator syntax for Effect, which I think unlocks mainstream adoption potential. https://twitter.com/MichaelArnaldi/status/1785061608894451725 https://twitter.com/MichaelArnaldi/status/178506160889445172... https://github.com/microsoft/TypeScript/pull/58337 https://github.com/microsoft/TypeScript/pull/58337

morbicer 2y ago
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.
- bjacobso 2y ago
  that is certainly a possibility
- steve_adams_86 2y ago
  I agree in some contexts. Kind of like Rust, I see a place for more durable code that's harder to reason about in some cases. 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.
- k__ 2y ago
  Yes it's quite sad. 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.
- Stoids 2y ago
  I think going all-in on Effect in its current state is not something I'd do. However there's a subset of its functionality that I'm currently replicating with a bunch of different libraries: ts-pattern, zod, some lightweight result / option wrapper like ts-belt, etc. Pretty much trying to pretend I'm writing ML / OCaml. Having those all in one package is quite convenient. Add in TypeScript's the much needed story around retry / observability / error handling—I see why people lean into it. 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.
steve_adams_86 2y ago
I agree about the turning point. Things have improved dramatically. And I know it probably doesn't feel the same for tons of people, but I love to see generators being used in every day code. The learning curve just about turned me away from it at the start, but I'm glad I stuck with it. I think learning Effect would actually teach a lot of people some very useful concepts and patterns for programming in general. It's very well thought out.
dimal 2y ago
How did you find learning Effect? The sales pitch sounds great, but when I went through the docs it seemed pretty confusing to me. I’m sure there are reasons for the everything but I couldn’t grok it. In particular, I’m thinking of the Express integration example.[0] I look at that and think, I need all that just to create a server and a route? What’s the benefit there? I’m hesitant to buy into the ecosystem after looking at that. I want to like it, though. [0] https://effect.website/docs/integrations/express https://effect.website/docs/integrations/express
- theschwa 2y ago
  Yeah, looking at that example feels like jumping straight into the deep end of the pool. I think it helps going through a tutorial that breaks down the why of each piece. I really liked this tutorial on it: https://www.typeonce.dev/course/effect-beginners-complete-getting-started https://www.typeonce.dev/course/effect-beginners-complete-ge... Some core things from Effect though that you can see in that Express example: * Break things down into Services. Effect handles dependency injection, that's typed, for services so you can easily test them and have different versions running for testing, production, etc. * Fibers for threaded execution * Managing resources to make sure they're properly closed with scope I think a lot of these things though often aren't truly appreciated until you've had something go wrong before or you've had to build a system to manage them yourself. *
  - dimal 2y ago
    Yeah, this looks like the tutorial I needed. Thanks.
  - mewpmewp2 2y ago
    But I feel like I've worked with massive systems with a lot going on where nothing has gone wrong that this sort of thing specifically would solve it. I think it would just increase learning curve and make people make other types of mistakes (business logic or otherwise) because it's so much less readable and understandable. I've seen similar libraries used in the past that have caused much more worse bugs because people misunderstand how they exactly work.

Aeolun 2y ago

I like the functionality, but the verbosity of the API makes me want to immediately ignore it. I feel like zod nailed the usability part.

epolanski 2y ago
Schema is a much powerful tool than Zod. Zod is merely a parser, while Schema has a decoder/encoder architecture.

seer 2y ago

I’d love to hear more stories of people using Effect in production codebases. It looks very similar in its ideas to fp-ts (in the “let’s bring monads, algebraic types etc to typescript” sense). But I did hear from teams that embraced fp-ts that things kinda ground to a halt for them. And those were category theory enthusiasts that were very good scala devs so I’m sure they knew what they were doing with fp-ts. What happened was that the typescript compile time just shot into minutes, for a moderately sized micro-service, without anything externally heavy being introduced like you could on the frontend. It just turned out that Typescript compiler was not so great at tracking all the inferred types throughout the codebase. So wonder if things have improved or effect uses types more intelligently so that this is not an issue.

golergka 2y ago
> It looks very similar in its ideas to fp-ts (in the “let’s bring monads, algebraic types etc to typescript” sense). It's the next version of fp-ts, developed by the same people, AFAIK

skrebbel 2y ago

Like Java, you can write Haskell in any language but that doesn't mean it's always a good idea.

MichaelArnaldi 2y ago
Which is why our principle with Effect is NOT to port Haskell. For example we don't use Typeclasses which are big in haskell, we lean heavily on variance which is not in Haskell. It's an ecosystem though to write production-grade TypeScript, not Haskell in TypeScript

williamcotton 2y ago

Why not write your code in F# and compile it to TypeScript using Fable [1]? This way you can use native language features for discriminated unions, functional pipelines, and exhaustive pattern matching to model your domain instead of shoe-horning such functionality into a non-ML language! Model your domain in F#, consume it in Python or C# backends and TypeScript frontends. The downside is needing to know all of these languages and run times but I think I'd rather know F# and the quirks with interacting with TypeScript than a library like Effect! [1] https://fable.io https://fable.io

steve_adams_86 2y ago
This is so cool! I’ll have to try it out soon. Thanks!
MichaelArnaldi 2y ago
https://effect.website/docs/other/myths#effect-should-be-a-language-or-use-a-different-language https://effect.website/docs/other/myths#effect-should-be-a-l...
IshKebab 2y ago
I've tried compile-to-JS languages before but their big weaknesses are: 1. Debugging can become quite a pain. Nobody likes debugging generated code. 2. You don't get to use libraries and tools from the enormous JavaScript ecosystem. 3. Eventually you'll find some web feature that they haven't wrapped in your language and then you're in for FFI pain. In the end I found Typescript was good enough that it wasn't worth dealing with those issues.
- deleted 2y ago
  [deleted]
- williamcotton 2y ago
  Fable is still very much integrated with the runtime so there’s an expectation to handle those bullet points with inline annotations. You can build an entire application in F# and compile to JS but another option is compiling to TS and calling that F# code from your TS app. I/O and views and whatnot are written in TS and the domain model is in F#. The entire model could be nothing but pure functions and resolve to a single expression!

aswerty 2y ago

Effect reminds me more of something like NestJS - essentially an end to end application framework that takes over your whole application. Rather disappoint to see something like this being plugged as an alternative to something like zod which is a nice library that stays in its corner and has a nice fixed scope to it's functionality.