The thing with abstracted away promises about effect HOT 4 CLOSED

I'm pretty sure that the return type of the effect will represent the async nature.

e.g. if you return a promise from an "Effect creating function" then the type signature will be:

Effect.Effect<never, never, Promise<number>>

I personally think adding an API to the library to represent async functionality is redundant and will make the library unnecessarily verbose. Effect is not a functional programming library and it isn't advertised to be. Its a library to add composability to a JS code base.

Watch this video for more details https://www.youtube.com/watch?v=zrNr3JVUc8I, and if you want a more strict functional library than use fp-ts.

from effect.

We had tried a few different options to track the Async Effect, in reality they all lead to worst DX without actually being safe. Namely even a fully Sync type should support a fromCallback combinator to enable usage with APIs that implement CPS, if such function exist it is impossible at the type level to assert that such function is called immediately and not deferred. So at the end we decided that the price of tracking (lack of composability) together with the inherent lack of safety (if Sync has to be complete it can't be safe) we decided that it isn't worth having separated types.

Notice that in general one should only run Effect at the edges of your app, in an app that uses Effect for everything that is a single call to the main effect and in such case the best way to run is directly using runFork, sync execution is a special case that is needed in environments where async execution is impossible and should be considered an edge case, i.e. use runPromise/runFork when you can, use runSync when you really have to.

from effect.

You are talking about a different thing. Example:
https://www.effect.website/docs/essentials/creating#effecttrypromise

Promise not encoded in type system, yet try runSync it -> no type error, but runtime error.

from effect.

I understand. Thank for you reply.

I've did some experimentation and realized, due to the nature of Promises in JS its hard to really ensure handling them properly, regardless whether you try to make them explicit in the type or not. Any attempt to tackle it leads to unnecessary calls required to ensure it was not left unhandled or it leaves open holes and hence does not remove the unsafe feeling of "is it actually safe to run or not".

I think its simply a natural limitation and manifests itself in different forms, no matter how you try to move it.

I guess I'll close this one then. In case there is any reason to leave this open, just reopen.

Thank you.

from effect.