Ok, I think John was right about IO bifunctor..
Ok, I think John was right about IO bifunctor.. A while ago there a post on how IO in scalaz had both a F and an E to reflect the error type that is more specific than Throwable . Cat has MonadError and ApplicativeError that assumes the error is a Throwable . That has alot of implications all up and down the APIs. Just as F has to be everywhere, once you want to customize the error to be more specific than Throwable or not related to Throwable at all much like as described in https://typelevel.org/blog/2018/11/28/http4s-error-handling-mtl-2.html , you have to fix all the APIs all the way down. That means the post http://degoes.net/articles/bifunctor-io from John was kind of right in my eyes. Once you do the work to be anything more specific, you might as well be explicit everywhere since one the flood gates open, that’s it. You can always be less specific. I ran into this issue when creating some specialized scala HTTP client’s that have a wide variety of