Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added FAQ item diff between cats and scalaz #1901

Merged
merged 14 commits into from
Sep 14, 2017
11 changes: 10 additions & 1 deletion docs/src/main/tut/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@ position: 4
# Frequently Asked Questions

## Questions

* [What imports do I need?](#what-imports)
* [What is the difference between cats and scalaz](#diff-scalaz)
* [Where is right-biased `Either`?](#either)
* [Why is the compiler having trouble with types with more than one type parameter?](#si-2712)
* [Why can't the compiler find implicit instances for Future?](#future-instances)
Expand All @@ -36,6 +36,15 @@ import cats.implicits._

This should be all that you need, but if you'd like to learn more about the details of imports than you can check out the [import guide](typeclasses/imports.html).

## <a id="diff-scalaz" href="#diff-scalaz"></a>What is the difference between Cats and Scalaz?

Cats and [Scalaz](https://github.com/scalaz/scalaz) has the same goal: facilitate pure functional programming in Scala applications; the underlying core strategy is different. Scalaz took the approach of trying to provide a single batteries-included *standard library* for FP that powers the Scala applications. Cats, on the other hand, aims to help build an [ecosystem](/cats/#ecosystem) of pure FP libraries by providing a solid and stable foundation. These libaries can have their own styles and personalities, competing with each other, while at the same time playing nice. It is through this ecosystem of FP libraries (cats included) that Scala applications can be powered with "FP awesome-ness" and beyond by picking whatever best fit their needs.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cats and Scalaz have the same goal


Based on this core strategy, Cats took a [modular](/cats/#modularity) approach and focuses on providing core, [binary compatible](/cats/#a-namebinary-compatibility-and-versioning), [approachable](/cats/#approachability) and [efficient](/cats/#efficiency) abstractions. It provides a welcoming and supportive environment for the [user community](https://gitter.im/typelevel/cats) governed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cats takes*?

by the [typelevel code of conduct](https://typelevel.org/conduct). It also takes great effort in supplying a comprehensive and beginner-friendly [documentation](/cats/#documentation).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not sure we can say this. I don't know where else we say this in the docs but I really don't think it's the case.

Copy link
Contributor Author

@kailuowang kailuowang Sep 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure which part you are referring to, is it "great effort" or "comprehensive" or "beginner-friendly"?


We believe that both Cats and Scalaz strategies have their merits and shortcomings, and it's a positive thing for the scala community to have both.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw this in gitter - I think it could either be:

We believe that the Cats and Scalaz strategies have their own merits and shortcomings, and it's a positive thing for the Scala community to have both.

or

We believe that Cats' and Scalaz' strategies have their own merits and shortcomings, and it's a positive thing for the Scala community to have both.


## <a id="either" href="#either"></a>Where is right-biased Either?
Up through Cats 0.7.x we had `cats.data.Xor`, which was effectively `scala.util.Either`, but right-biased by default and with
a bunch of useful combinators around it. In Scala 2.12.x `Either`
Expand Down