kyo VS capslock

Indeed - I do not think it is a coincidence that a lot of production experiments in effect systems are happening in Scala right now - the language is very flexible to conduct them. https://github.com/getkyo/kyo in particular looks interesting as it explores a different space where the monadic nature is less exposed to the end user.

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.

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:

Wow I’ve been thinking of something exactly like this! Sort of a super charged, statically typed version of Go’s context.Context. It would allow you to describe the capabilities (or effects) of every function, including IO, memory allocation, cancellation, deadlines, concurrency, and whatever application-specific stuff you need on there (like logging).

Then you could implement something like Google [0] just by looking at type signatures.

0. https://github.com/google/capslock