8 replies

Discussion on Tracking Asynchronous Effects in Type System

If you run an asynchronous effect with

runSync

runSync

, you get a runtime error but no type error. It would be nice if we could keep track of which effects are asynchronous so we could prevent this.

On the Effect website, it mentions that this was considered but ultimately dropped for 2 reasons:

1. Complexity: Introducing this feature to track sync/async behavior in the type system would make Effect more complex to use and limit its composability.
2. Safety Concerns: We experimented with different approaches to track asynchronous Effects, but they all resulted in a worse developer experience without significantly improving safety. Even with fully synchronous types, we needed to support a fromCallback combinator to work with APIs using Continuation-Passing Style (CPS). However, at the type level, it’s impossible to guarantee that such a function is always called immediately and not deferred.

1. Complexity: Introducing this feature to track sync/async behavior in the type system would make Effect more complex to use and limit its composability.
2. Safety Concerns: We experimented with different approaches to track asynchronous Effects, but they all resulted in a worse developer experience without significantly improving safety. Even with fully synchronous types, we needed to support a fromCallback combinator to work with APIs using Continuation-Passing Style (CPS). However, at the type level, it’s impossible to guarantee that such a function is always called immediately and not deferred.

1. Complexity: Introducing this feature to track sync/async behavior in the type system would make Effect more complex to use and limit its composability.
2. Safety Concerns: We experimented with different approaches to track asynchronous Effects, but they all resulted in a worse developer experience without significantly improving safety. Even with fully synchronous types, we needed to support a fromCallback combinator to work with APIs using Continuation-Passing Style (CPS). However, at the type level, it’s impossible to guarantee that such a function is always called immediately and not deferred.

1. Complexity: Introducing this feature to track sync/async behavior in the type system would make Effect more complex to use and limit its composability.
2. Safety Concerns: We experimented with different approaches to track asynchronous Effects, but they all resulted in a worse developer experience without significantly improving safety. Even with fully synchronous types, we needed to support a fromCallback combinator to work with APIs using Continuation-Passing Style (CPS). However, at the type level, it’s impossible to guarantee that such a function is always called immediately and not deferred.

[from https://effect.website/docs/getting-started/running-effects/#synchronous-vs-asynchronous-effects]

I'm not sure what was tried in earlier versions that led to this conclusion (I could be totally missing something!), but I can imagine a relatively straightforward way to implement this check that would not limit composability or harm dx.

I'll continue in the thread since I'm length limited ->

Effect Documentation

Running Effects

Learn how to execute effects in Effect with various functions for synchronous and asynchronous execution, including handling results and managing error outcomes.

Discussion on Tracking Asynchronous Effects in Type System

Similar Threads

Similar Threads

Similar Threads