Beyond that, I discussed with @marcraminv the contents of the current TCP echo server - concurrent system with Fibers section. And we conclude that most of it is hard to read and understand. As I'm the author it pains me to admit it :) , but it is likely we should replace it with something easier to follow. E.g. we considered implementing a solution for the producer-consumer problem. What do you think?
Producer-consumer seems a lot easier to follow! Like, I love the TCP echo server concept, but it's definitely difficult to follow and requires some setup.
Something I've struggled with sometimes is whether or not it's worth referencing ecosystem projects
background
get back the concurrent execution as a resource. That also is not completing the work somehow.
Resource
inside your biz logic
cats-mtl
, but what if you need to eventually provide a context and convert reader-like G
to a non-reader F
?
i usually use the former, and usually add
trait Train[F[_]] {
def toot(): F[Unit]
def mapK[G[_]](f: F ~> G): Train[G]
}
(cats-tagless can auto-generate these also)
Kleisli
vs. ApplicativeAsk
, that's one choice
F
s with different contexts.Lift
/Unlift
classes for conversion back and forth.ConnectionIO
and second to Kleisli[ConnectionIO, ...]
, both with its own lifts-unlifts
class BizLogic[F[_]](alg1: Alg1[F], alg2[Kleisli[F, Dependency]])
? because something like that would be difficult.
def withRequestId[F[_], G[_] : WithRun[*[_], F, RequestId[F]](routes: HttpRoutes[F]): HttpRoutes[G]