[dimal]

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

[obeavs]

Hands down, the best (free, no email) resource to learn Effect is here https://www.typeonce.dev/course/effect-beginners-complete-ge..., as opposed to the docs. The link referenced gives a holistic view of how to incorporate it.

[satvikpendem]

I've been following the author Sandro Maglione for quite a while and am on his email list, he's great. He wrote fpdart which I've used and now he seems to be all in on Effect, with XState.

[wruza]

That’s just another level. Only in five pages of explanations we come to something that is basically:

  await fetch(…)
    .catch(e =>
      new CustomError(…))

But with a wrapped-promise and flatmap nonsense for “better error handling”.

FP always goes out of the way to avoid using the language it operates in and to criticize the ways of doing something it just imagined. As if it wanted to stay as noble from unwashed peasants as it could, but has to do the same job to keep existing.

how to test () => makePayment()? (from the link)

You don’t. You test constituents like request body generation and response handling. It’s inside. You can’t test your Effect-version of this code neither. It’s a strawman.

[theschwa]

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-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. *

[mewpmewp2]

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.

[dimal]

Yeah, this looks like the tutorial I needed. Thanks.

[bjacobso]

I agree, some of there examples are a little overly complicated by their quest to be hyper composable. In fact they should probably remove that example. I am currently using it with Remix, and using their @effect/platform package to produce a simple web handler (request: Request) => Response (thank remix for heavily promoting the adoption of web standards).

I fully agree parts of the ecosystem are complex, and likely not fully ready for broad adoption. But I do think things will simplify with time, patterns will emerge, and it will be seen as react-for-the-backend, the de facto first choice. effect + schema + platform + cluster will be an extremely compelling stack.