The future: Scalaz, Cats, both, or neither?

Ground rules

Scalaz 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.

The present

Currently, we are a unabashedly a Scalaz library. We get this transitive dependency from scalaz-stream, so we might as well use it.

The looming change

Soon, scalaz-stream will be decoupled. 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.

Once we depend on this version of scalaz-stream, tentatively to be branded 0.9, the Scalaz decision is no longer made for us.

Ways forward

Decouple core from either library

Pros:

• Follows streams’ philosophy that “The ecosystem should not pick a winner.”
• Imposes no new dependencies on us beyond streams.
• Does not bifurcate our community.

Cons:

• Forces us to settle for inferior types (e.g., scala.Either vs. scalaz.\/) or reinvent them.
• Other similarly principled libraries (e.g., doobie, remotely) will need similar reinventions, and without using a library, provide a worse interop experience.
• Instances could be supplied by http4s-scalaz and/or http4s-cats integration modules, but would no longer conveniently appear in companion objects.

Short term impact:

• We should move all direct Scalaz dependencies to a support module or delete them.

Build on Scalaz

Pros:

• No additional breaking changes
• Matches current state of doobie and remotely. This is no guarantee those projects don’t change.

Cons:

• Gives second-class status to Cats projects.
• Scalaz is already discussing an incompatible version 8. That’s basically a whole new library.

Short term impact:

• None

Build on Cats

Pros:

• Cats has a rapidly growing community.
• Our existing maintainers contribute more to Cats than Scalaz.

Cons:

• Less mature than Scalaz, further pushing out our timeline for a long-term support API.
• Gives second-class status to Scalaz projects, which are presently more numerous.

Short term impact:

• 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.
• Consider migrating instance layout to match Cats conventions.

Cross-build

Pros:

• http4s is positioned well if either or both libraries continue on strong.

Cons:

• Maintaining cross-build stretches thin development team even thinner.
• Some who have tried cross-building advise that this way madness lies.
• Depending how we do it, restricts us to the intersection of functionality supported by Scalaz and Cats.

Short term impact:

• None

[rossabaker]

Tentatively, we’re keeping master on scalaz-stream while release-0.15.x is actively maintained to preserve the release-0.15.x -> master -> cats flow. I anticipate we’ll flip the branches after 0.16 is released to get cats front and center.

We’re publishing mostly complete snapshots on cats+fs2 and have documented the gaps. The work continues, but I think this ticket ends here.

[mdedetrich]

I personally prefer Cats, and the preference is due to a technical one. Cats puts an emphasis on modularity and stability (API/Binary stability, massive emphasis on testing). I have been bitten many times in the past due to Scalaz’s monolithic design (coupled with its its attempt to reinvent the scala stdlib). At least for the medium/long term, it seems a better decision as you would strictly only need to pull in the parts of cats that you need (which would probably be whatever a cats-stream/cats-task would pull in)

In regards to pathways, I don’t see the merit in supporting both Cats/Scalaz. Its a huge amount of work, and may be setting the wrong precedent. Http4s should be using the library which best aligns with its goals of stability, and Cats is follows this a lot harder than Scalaz.

For now, I would also decouple JSON from this discussion, I think its a separate issue, mainly for the reason we can always add in JSON support for library X through some external modules (i.e. http4s-argonaut). Such modules can bring in whatever they want, but stuff like stream/task is so central to http4s, that it really needs to use something that is more stable/modular