cps-async-connect VS kyo

Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.

Also, support for probability monad (https://github.com/jliszka/probability-monad ) is added to cps-async-connect. Now it is possible to do probabilistic programming in scala with direct style: https://github.com/rssh/cps-async-connect/blob/master/probability-monad/src/test/scala/cps/monads/probability/ProbabilityExamplesSuite.scala )

cps-connect-async: https://github.com/rssh/cps-async-connect

Hmm, you can write direct-style code with monad: https://github.com/rssh/dotty-cps-async allows this, exists support libraries exist for near all well-known effect systems: https://github.com/rssh/cps-async-connect, so you can use async/await with IO/ZIO the same as with Future. Although in IO style, any operation that mutates state is async, it's hard to write code where you should place `await` near each line. And it looks like automatic coloring is a too radical change of concepts for most functional programmers. The option to allow using <- in the direct style may be more popular, but this requires changes to the scala core. Another question - are we need effective systems to be present in each program in industrial-style development? Here I agree that mostly no.

integration libraries (https://github.com/rssh/cps-async-connect ) for akka-stream, cats-effects, fs2, monix, scalaz and zio

Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.

Here's the link to the repo: https://github.com/fwbrasil/kyo

Thanks! I'm not sure I understand your use case but it's possible to handle effects even if they aren't present in the computation. An example of that is KyoApp's run method. It handles several effects even thought the application might not use them:

The project actually has an IO effect and concurrency primitives. I think the ZIO integration will play an important role but the goal is to have a complete effect system carefully crafted for high-performance.