{"action":"created","issue":{"url":"https://api.github.com/repos/http4s/http4s/issues/390","repository_url":"https://api.github.com/repos/http4s/http4s","labels_url":"https://api.github.com/repos/http4s/http4s/issues/390/labels{/name}","comments_url":"https://api.github.com/repos/http4s/http4s/issues/390/comments","events_url":"https://api.github.com/repos/http4s/http4s/issues/390/events","html_url":"https://github.com/http4s/http4s/issues/390","id":102034248,"number":390,"title":"The future: Scalaz, Cats, both, or neither?","user":{"login":"rossabaker","id":142698,"avatar_url":"https://avatars.githubusercontent.com/u/142698?v=3","gravatar_id":"","url":"https://api.github.com/users/rossabaker","html_url":"https://github.com/rossabaker","followers_url":"https://api.github.com/users/rossabaker/followers","following_url":"https://api.github.com/users/rossabaker/following{/other_user}","gists_url":"https://api.github.com/users/rossabaker/gists{/gist_id}","starred_url":"https://api.github.com/users/rossabaker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rossabaker/subscriptions","organizations_url":"https://api.github.com/users/rossabaker/orgs","repos_url":"https://api.github.com/users/rossabaker/repos","events_url":"https://api.github.com/users/rossabaker/events{/privacy}","received_events_url":"https://api.github.com/users/rossabaker/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/http4s/http4s/labels/meta","name":"meta","color":"eb6420"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":16,"created_at":"2015-08-20T01:07:08Z","updated_at":"2016-07-18T20:14:42Z","closed_at":null,"body":"## Ground rules\r\n\r\nScalaz and Cats provide a lot of overlapping functionality that is useful to our library.  Each has a both a devoted following and strong detractors.  We are not here to discuss history or politics, but to transparently decide the way forward for this project.\r\n\r\n## The present\r\n\r\nCurrently, we are a unabashedly a Scalaz library.  We get this transitive dependency from scalaz-stream, so we might as well use it.  \r\n\r\n## The looming change\r\n\r\nSoon, [scalaz-stream will be decoupled](https://github.com/scalaz/scalaz-stream#issues/321).  The approach taken there is to not depend on either Scalaz or Cats, and redefine its own foundational type classes (e.g., Monad) as necessary.\r\n\r\nOnce we depend on this version of scalaz-stream, tentatively to be branded 0.9, the Scalaz decision is no longer made for us.\r\n\r\n## Ways forward\r\n\r\n### Decouple core from either library\r\n\r\nPros:\r\n* Follows streams' philosophy that \"The ecosystem should not pick a winner.\" \r\n* Imposes no new dependencies on us beyond streams.\r\n* Does not bifurcate our community.\r\n\r\nCons:\r\n* Forces us to settle for inferior types (e.g., `scala.Either` vs. `scalaz.\\/`) or reinvent them.\r\n* Other similarly principled libraries (e.g., doobie, remotely) will need similar reinventions, and without using a library, provide a worse interop experience.\r\n* Instances could be supplied by http4s-scalaz and/or http4s-cats integration modules, but would no longer conveniently appear in companion objects.\r\n\r\nShort term impact:\r\n* We should move all direct Scalaz dependencies to a support module or delete them.\r\n\r\n### Build on Scalaz\r\n\r\nPros:\r\n* No additional breaking changes\r\n* Matches current state of doobie and remotely.  This is no guarantee those projects don't change.\r\n\r\nCons:\r\n* Gives second-class status to Cats projects.\r\n* Scalaz is already discussing an incompatible version 8.  That's basically a whole new library.\r\n\r\nShort term impact:\r\n* None\r\n\r\n### Build on Cats\r\n\r\nPros:\r\n* Cats has a rapidly growing community.\r\n* Our existing maintainers contribute more to Cats than Scalaz.\r\n\r\nCons:\r\n* Less mature than Scalaz, further pushing out our timeline for a long-term support API.\r\n* Gives second-class status to Scalaz projects, which are presently more numerous.\r\n\r\nShort term impact:\r\n* Keep building on Scalaz, as long as the concept is or is expected to appear in Cats.  Some API will change, but the concepts are the same.\r\n* <ins>Consider migrating instance layout to match Cats conventions</ins>.\r\n\r\n### Cross-build\r\n\r\nPros:\r\n* http4s is positioned well if either or both libraries continue on strong.\r\n\r\nCons:\r\n* Maintaining cross-build stretches thin development team even thinner.\r\n* Some who have tried cross-building advise that this way madness lies.\r\n* Depending how we do it, restricts us to the intersection of functionality supported by Scalaz and Cats.\r\n\r\nShort term impact:\r\n* None"},"comment":{"url":"https://api.github.com/repos/http4s/http4s/issues/comments/233444630","html_url":"https://github.com/http4s/http4s/issues/390#issuecomment-233444630","issue_url":"https://api.github.com/repos/http4s/http4s/issues/390","id":233444630,"user":{"login":"rossabaker","id":142698,"avatar_url":"https://avatars.githubusercontent.com/u/142698?v=3","gravatar_id":"","url":"https://api.github.com/users/rossabaker","html_url":"https://github.com/rossabaker","followers_url":"https://api.github.com/users/rossabaker/followers","following_url":"https://api.github.com/users/rossabaker/following{/other_user}","gists_url":"https://api.github.com/users/rossabaker/gists{/gist_id}","starred_url":"https://api.github.com/users/rossabaker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rossabaker/subscriptions","organizations_url":"https://api.github.com/users/rossabaker/orgs","repos_url":"https://api.github.com/users/rossabaker/repos","events_url":"https://api.github.com/users/rossabaker/events{/privacy}","received_events_url":"https://api.github.com/users/rossabaker/received_events","type":"User","site_admin":false},"created_at":"2016-07-18T20:14:42Z","updated_at":"2016-07-18T20:14:42Z","body":"Not only does it support both category libraries, it supports both streaming libraries.  It also is transparent: no shim types in the public API, no additional imports.  The pain is entirely the library's.  And it does hurt.\r\n\r\nStacks that could be supported natively with this:\r\n\r\n1) scalaz + scalaz-stream\r\n2) scalaz + fs2\r\n3) cats + scalaz-stream\r\n4) cats + fs2\r\n\r\nAmong these, 1 and 4 are compelling to me.  2 could be compelling to the community, and comes along free with the work in 1 and 4.  3 is the unwanted quadrant, I suspect.\r\n\r\nBecause scalaz+fs2 is more compelling than cats+scalaz-stream, I'm attempting the fs2 port first.  See the topic/yax branch as I hack and whack.  I am not yet committed to this approach, but would love feedback.  In the worst case, the yax-generated source can seed an eventual move to fs2."}}
{"actor":{"display_login":"rossabaker"}}