5 ms·

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 Effe

• 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.
    • rashkov 2y ago
      Coming from a ReasonML / OCaml codebase (frontend react), I'm seeing a lot to love with the pattern matching and sum types. Zod is already one of my favorites (coming from https://github.com/glennsl/bs-json https://github.com/glennsl/bs-json). Is 'retry / observability / error handling" something that comes from Effect?
      • Stoids 2y ago
        That's right, Effect lifts all types to a lazily-evaluated common type and provides combinators to work with that type, similar to RxJS with Observables and its operators. 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 https://effect.website/docs/guides/error-management/retrying [1] https://effect.website/docs/guides/observability/telemetry/tracing#creating-spans https://effect.website/docs/guides/observability/telemetry/t... [2] https://effect.website/docs/guides/error-management/expected-errors https://effect.website/docs/guides/error-management/expected...
  • epolanski 2y ago
    Effect is not only much easier to get productive on than Ramda, but it provides an entire ecosystem. Our team is full effect from two years and juniors can pick it and start working on it with ease.
    • steve_adams_86 2y ago
      Having references to work from is essential. Their documentation doesn’t do as good of a job demonstrating that as it could, in my opinion.
      • yunohn 2y ago
        I’ve found that with most libraries - they always provide toy foobar style examples assuming it’ll make them approachable, but in reality, instead makes it impossible to understand the practical way to use it in real world settings.
        • hombre_fatal 2y ago
          Reminds me of Animal / Cat / Dog examples. For the love of god just use User / RegisteredUser / GuestUser and other abstractions that have some basis in the real world.
        • epolanski 2y ago
          That is quite of an hard problem to solve. 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.
  • presentation 2y ago
    My experience with fp-ts and io-ts was that we quickly got to a point where the team was divided into a small group of people usually with postgraduate CS degrees who really understood it, and then everyone else who saw it as black magic and were afraid to touch it. Nowadays I’d rather rely on libraries that don’t require a phd to use them properly.
    • hombre_fatal 2y ago
      You just gave me a flashback to scalaz https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz
  • hresvelgr 2y ago
    > Me and my team reverted to more stupid code and we are happier. 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.
    • BillyTheKing 2y ago
      Yes, all true - apart from treating errors as values and including them function signatures... That should simply be something every modern language should ship with
      • Sammi 2y ago
        I have never written any code in Go, but increasingly I am writing my TS in the style I hear Go code is written in. Very procedural, very verbose. All of the fancy indirection you get with coding everything with higher order functions just makes the program impossible to debug later. Procedural style programming lends itself to debugging, and I definitely am so dumb I need to debug my own programs. 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.
  • MichaelArnaldi 2y ago
    Don't judge Effect based on Rambda they have completely different objectives, Rambda focused a lot on abstractions similar to fp-ts, Effect focuses almost exclusively on concrete implementations
    • evilduck 2y ago
      It's not the library per se, it's that the library will require all-or-nothing buy in from your entire development team for it to be useful and persistently maintained, similar to how Rambda affected a codebase and a development team. 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.
      • steve_adams_86 2y ago
        One of the things I like about Effect is that incremental adoption is easy, and you really don't have to use it everywhere. 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.
        • evilduck 2y ago
          I understand, but this is very much like promises in JS. You can pass promises around without awaiting their return values too but async and/or promise code inevitably infects the rest of the codebase. I've never really seen anyone just have promises walled off in one specific module where the rest of the codebase sticks to callbacks. 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.
• 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.