如何評價scalaz這個庫？

01-07

scalaz使用scala的方式實現了type class, 並在其基礎上實現了Functor, Semigroup, Monoid, Monad etc. 幾乎是用Haskell的方式在寫scala.
如何評價這個庫？現在是不是scala社區的主流？如果不是，會不會是主流？會對scala的程序設計產生什麼影響嗎？

斜腰，爪機作答，有誤莫噴。

是不是主流？是不是主流要看怎麼定義，基本上我參加過的的scala conf, 都會有小團隊互相問，你們用了scalaz沒？然後大家互相發出蜜汁微笑....。

要不要學？假如時間不是你的敵人，會建議直接跳過，去看一下Haskell （中級程度教程）。因為要看理論基礎的話...scala語法在這裡其實是噪音....

會不會產生設計影響？影響設計的是業務需求，系統結構和運行環境，用不用某個庫是以上需求確認後的選型，當然，多了解各種庫的功能總是對選型有幫助的。比如Binding.scala...(被洗腦的廣告....

用不用得上？絕對可以，甚至你可能在用都不知道....

為啥會有這個庫？FP老司機們看到scala的第一天就罵這個是語言是異端，scalaz是來正本清源的。（例子，map/flatmap....

Scala很易用。但Scalaz很難用。

Scalaz的變數命名十分糟糕、濫用特殊字元，違反社區規範，導致代碼很難讀懂。scalaz在Scala變數名長度大賽中名列倒數第一。平均長度只有1.7個字元。相比之下，我寫的zero-log變數名長度乃是排行正數第一，代碼很易讀。
其次，Scalaz為了模擬Haskell的type class，用了很多奇技淫巧，比如Unapply和Ops。實際上這些功能應該通過Scala編譯器本身提供、至少應該實現在宏裡面。像simulacrum和si2712fix-plugin的做法才是正解。
Scalaz的版本號違反Semver，比如7.1和7.2就互不兼容。這麼亂搞很容易破壞那些依賴了Scalaz的庫的向後兼容性。
Scalaz的包結構很混亂，把數據結構和type class都放在一起。相比之下typelevel/cats就好得多。

Scalaz難用是顯而易見的事實，我見過抱怨Scala難學的人，基本上都是在抱怨Scalaz，而他們對Scala語言本身學得很快。

不幸的是，很多人誤以為用Scala就必學Scalaz，因而誤以為Scala是一門很複雜的語言。

實際上這是錯的。Scala上的那些最實用的開源軟體中，除了Binding.scala，其他的Spark、Akka、Kafka都沒有使用Scalaz。

Scalaz可能是造成Scala被誤解的罪魁禍首。

我寫了一個庫（ThoughtWorksInc/each），把Scalaz里的monad封裝了一下，就變得好用了。

比如我自己就用ThoughtWorksInc/each搞了個前端框架叫Binding.scala。Binding.scala的用戶根本感覺不到這麼簡單易用的前端框架內部居然用了這麼難用的Scalaz。他們都說Binding.scala比ReactJS和AngularJS還要簡單的得多，紛紛用Binding.scala替換他們的ReactJS和AngularJS項目。

Scalaz 在當年還是有進步意義的，畢竟證明了可以用Scala寫Haskell代碼。不過時至今日，如果要在項目中使用Scalaz的monad的話，你可以用我封裝後的ThoughtWorksInc/each，而monad以外的功能推薦改用typelevel/cats。

謝邀。。。回答過了，又被邀請了。。

scalaz的起點算是Steal from Haskell，然後慢慢發展，現在主要是作為FP的core library, 圍繞它的有scalaz-concurrent，scalaz-effect，scalaz-stream等項目，它主要提供一些基礎的typeclass 和data structures。

當你想把一些paper上的東西(一般都是Haskell代碼描述)用Scala寫一下時，你會發現你需要一個像Haskell一樣的環境/基礎抽象，這時scalaz拿過來作為基礎庫就很順手了。（寫完原型後，可能會拋棄scalaz，把用到的東西重寫一遍，過於依賴就沒辦法了）

時隔一年，我仍然覺得，scalaz的代碼最好不要出現在直接的業務代碼中，因為有些東西過於general，像集合庫一樣用一些purely data structures還沒啥問題，別的東西還是用代碼分層隱藏一下比較好，至少擼個簡單的DSL吧！（這是Scala人的基本素養啊）

更正一下，並不是Haskell的方式寫Scala，而是FP的方式寫Scala（這個不展開了）

scalaz是新手不友好的，建議在學會Scala之後的進階階段再去學，去用

@楊博一直在努力讓人以最低的成本，最大地享受到Scala的能力/好處，我覺得這才是主流

-----------------------一年前老答案---------------

看過scalaz和shapeless，前者幾乎在重新定義語言，後者學習資料好少，除非你追求純以及低代碼信噪比否則實際中用不上，但是這兩個庫的學習還是很有價值的

本來是打算學scalaz的，因為公司里也有team在用，矽谷的很多公司也有用。但是…

scala兼容OO，語法上噪音太大了，本來OO轉FP就難… 學了幾天果斷轉學haskell.

現在看來，絕對是我人生中最正確的決定之一…

1) scalaz 在scala社區應該還算不上主流，但一些函數式偏好者比較喜歡用，也不乏一些很成功的開源產品中依賴了scalaz或shapeless的

2) 會不會成為主流，很難說。這要看類型系統的優勢(和複雜度)被大家接受的程度，我覺得不太容易。

3) 有點像是OO里的23種模式，對於類型系統來說scalaz/shapeless 也算是用類型和函數式的一些模式來解決問題

我覺得是因為很多Haskell的人開始涉足Scala才有的這個庫。因為JVM的限制，Scala的函數式特性支持沒有Haskell那麼完全，這個庫反映了一群haskell高手們在Scala上的探索吧。

覺得它未來可能成為標準庫的一部分。

我們搞工程的和他們搞PL的不是一類人。

我越來越覺得Scala是一門需要用一生來學習的語言...出一個lib就很有可能定義一套新語法。

有一些庫內部用了scalaz和shapeless。

雖然現在一般應用開發還不太需要用到這兩個庫，但我覺得在走向高階的庫開發者的過程中是需要研究一下這兩個庫的。

覺得它未來可能成為標準庫的一部分 -- 看路線圖上，標準庫將支持shapeless的HList和HArray