scala-gopher VS cps-async-connect

scala-gopher: https://github.com/rssh/scala-gopher

scala-gopher (https://github.com/rssh/scala-gopher ) implementation of CSP constructs, i.e. channels/selectors for scala.

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