Haskell適合做網站開發嗎？有什麼優缺點？

01-12

本人Haskell基本算是入門了最近接了個網站開發的活我先試試用Haskell來寫（為了攢Haskell經驗以方便找工作）看了幾個Haskell做的網站感覺不錯的樣子。有沒有哪位大神用過Haskell做網站的？聽說那個Yesod很好用的樣子？都有哪些優缺點，會不會有很多坑呢？網上搜了一些文章都是很多年前的了。哪位大神來簡單回答一下？

先吐槽一下

最近接了個網站開發的活我先試試用Haskell來寫（為了攢Haskell經驗以方便找工作）看了幾個Haskell做的網站感覺不錯的樣子。

如果是那種寫完能拍拍屁股走人的項目用Haskell還好, 不是並且需求變動多或者略奇葩的話還是乖乖用PHP/Python/Ruby挑個實用的框架就算. Web開發的知識經驗是基本上是語言無關的, 還有什麼工作需要Haskell經驗的請聯繫我, 好像並沒有多少不是玩票性質用Haskell寫的網站公開代碼, 不要看著前端寫得好看就感覺不錯 (

用Haskell做Web開發最大的優點大概只有"類型安全"這點(連HTTP都搞了個http-types: Generic HTTP types for Haskell), Rapid Prototyping這個別的語言框架都可以做到; 性能? Go, Rust這些新生代編譯語言性能已經不差, 並且Haskell的內存管理性能調優監控會的人鳳毛麟角, 談不上優勢.

具體到框架上, 比如說差不多跟Rails同一個量級的Yesod, 相對於別的比較全的框架比如Snap, Happstack, 更新比較快, 文檔健全, 周邊配套比較完善. 但是Yesod裡面有很多高級的類型魔法Type Family, Template Haskell 雖然可以不需要太了解這些特性就能寫出代碼, 但是出了問題或者偏離框架適合的應用場景(也就是你Google或者SO找不到代碼來複制粘貼)的時候就會沒輒. 最近發現Thoughtbot寫了個挺靠譜的例子thoughtbot/carnival · GitHub. 至於更加輕量的Scotty, Spock跟Sinatra差不多個路子 (

在兩三年前SPA開始慢慢出現時, 我感覺到Haskell, Scala這種語言挺適合開發API伺服器. 因為服務端跟客戶端通訊需要Contract, 強大的類型系統正好可以作為這個Contract(然而當時我並不知道Grape跟Swagger這種存在, 並且Haskell的類型系統不足以表達JSON Schema裡面的所有約束, 或許LiquidHaskell的Re?nement Types能夠滿足, 別跟我提SOAP, WSDL), 另外一點是這些語言做JSON(反)序列化會稍稍快些, 用上Aeson會飛 (

在那段時間到Servant出來之前大概有兩個東西比較出名, 一個是Silk出的Rest, 另一個是 postgrest, 前者通過一套DSL來定義數據模型(資源)生成服務端客戶端代碼,文檔, 後者直接在Postgre上套一層API, 這兩個的限制在於都限制在RESTful API上可定製性不是很高. 然後輪到Servant, 簡單來說Servant就是用Type-Level DSL來定義HTTP介面(不受限於REST), Type-Level DSL優勢在於能夠expose 類型信息, 比僅僅是結構的DSL好生成代碼得多, 打這麼多字好累, 看這裡好了 ChicagoHaskell/servant-presentation · GitHub 有代碼有slides

前端部分, Yesod那些莎士比亞模板語言還算能用. 主流的BlazeHtml , Lucid 都挺好看, CSS只有個 Clay. Compile2JS早點就有Fay, Haste都是實現GHC的子集, GHCJS漸漸能用, 但是為了實現Haskell的語言都拖著個Runtime, 生成的文件龐大, 也已經有FRP系統在上面實現(reflex). 語法特性類似Haskell的Purescript親和性更加好一點, 各種binding都比較齊全, 也有自己的生態.

至於坑, 用小眾語言做實際項目坑是不可避免的, 大眾語言大眾庫即便有坑多人踩了就有PR, Workaround, Haskell不但小眾而且語言問題也不好解決, 碰到個不懂的概念就好多時候就瞎眼. 開發網站用傳統的伺服器渲染, 在關係資料庫上CRUD能很好解決. 如果網站規模變大, 組件一多(Message/Job Queue, NoSQL DB, 各種Service), Haskell有些Binding或者DB Driver質量或者維護不是很好要麼就自己動手, 要麼就換別的語言的庫, 再跟各個組件通訊. 這種結構會給運維和系統穩定性帶來不少麻煩和風險.

即便如此, 不是不推薦用Haskell, 畢竟需要更多人填坑修路.

post-rfc/sotu.md at master · Gabriel439/post-rfc · GitHub

不妨參考State of the Haskell ecosystem裡面Server-side programming這一節。

可以跟其他語言的framework互相配合, 例如Haskell可以用來作前端跟後端, 再加上Django作Haskell後端的後端. 換句話說在Server這邊會先經過Haskell作前處理, 有更進階的需要才緊接著呼叫Python後端, 這用法自認比較靈活, 也可能是餿主意

前端Haskell推這個 valderman/haste-compiler · GitHub

其實寫網站這種東西，是典型適合面向過程的人來做的

用腳本做更快，而封裝之後，不管是oop的java還是fp的haskell之類的

開發起來都不會有多快，因為網站本身屬於邏輯簡單，數據也簡單的東西

強行封裝容易弄巧成拙，建議使用js，ruby等腳本來實現

當然你要說能不能，都能做，做網站可能是所有語言都能做的一個東西

techempower上上百個框架都能做網站

從這一方面上說，光做網站，也有點紅海的味道

要說適合不適合，感覺還是看人吧。

至於寫網站，其實沒必要死磕一門語言。

但是在不經意中，自己使用了Haskell 開發的了一個小網站。其中使用了Scotty，Blaze和Postgresql-simple，雖然不是很高大上，但是也算是趟了一些坑。

具體可以看此處：

TTalkIM的開發筆記-TTalkIM

適合。

cabal，npm，gulp管理代碼和資源。

yesod創建網路應用骨架，shakespeare模板語言用來（編譯型用於生產，運行時用於開發階段）。

persistent做資料庫的orm。

wai做網站中間件開發。

scotty，hspec-wai用於cabal的test-suite做單元測試。

haskell和c語言極易交互，可以方便地使用大量的c庫。

npm，gulp用作前端開發。

haskell開發最爽的是他的類型系統，以及強大的hackage資源

Haskell Sever Page( hsp )

hsp: Haskell Server Pages is a library for writing dynamic server-side web pages.