如何評價eta-lang？

01-13

Eta a€「 A powerful language for building scalable systems on the JVM
Eta Programming Language

很久以前，就有一個叫 Frege 的項目，也是一個 target 到 JVM 的 Haskell 實現，一直不溫不火，畢竟只是實現了 Haskell 2010 + 少數擴展，跟 GHC 不兼容，所以大多數 Hackage 上的庫沒法直接用。

後來就有人搞了個 GHCVM 項目，一開始基於 GHC API，借用了 GHC 前端，畢竟宗旨就是做一個跟 GHC 兼容、能用 Hackage 庫的 JVM 後端。結果呢。。當時基於 GHC 7.10.3 的介面做的，然後沒多久 GHC 8.0.1 發布了，很多介面大改。除了 GHCVM，還有一些其他的基於 GHC API 進行二次開發的 Haskell 編譯器（比如 Haste）也跟著一塊杯具了。。為了兼容 8.0.1 又得大改。所以這哥們索性決定自立門戶，項目名字從 GHCVM 改為 Eta，也不再以 GHC compatibility 為首要目標。。

嗯，就這樣。現在這年頭還想做 Haskell 編譯器，繞不開的問題就是到底兼不兼容 GHC。。不兼容的話太不實用，兼容的話太過辛苦。

謝邀，GHCVM這個項目是從 @閱千人而惜知己那裡知道的，後來有關注，但沒怎麼看。原來演變為eta項目了。

大致看了下用eta寫的代碼，感覺還是挺好的。下面就我所看到的說一說。

首先，eta是直接生成了jvm可執行的位元組碼，因此其和java的class之間的調用是無縫的。通過FFI介面即可和java的代碼相互調用。而且eta的callstack和java的callstack是對齊的。

其次，eta直接使用了GHC的前端，直到stg都是一樣的，在stg之後就開始和標準的GHC不同了。因此和原生的haskell代碼兼容性很好。主要的問題就是ghc 8.0發布後，新增了不少語言擴展，很多package的新版本不能編譯。這個可以使用stack來管理eta可以使用的package，另外eta開發者也在討論這個問題，尋找積極的解決方法，目前已經確定會將部分ghc 8.0點特性加入到eta中，比如Strict和ApplicativeDo。從郵件來看，他們還是比較務實的。

另外，和C的介面方面，eta也有類似JNI的介面JNR來調用C代碼，避開了繁重的C FFI介面，據說在有些case下速度還是不錯的。

在性能方面，eta有一個jvm上的高效tail call的實現，另外jvm也在慢慢的變得更加友好的支持函數式編程語言。

在移動應用開發方面，GHC本身是很不方便的，難以和Android系統有較好的結合，難以方便的使用Android系統中已有的系統組件。我曾經移植了ghc 8.0到Android 6.0上，且成功編譯出了基於opengl的應用。但有兩個主要問題，一個是和Android系統的交互比較麻煩，另一個是生成的應用非常大。一個簡單的應用的apk就有10M多，其中haskell代碼生成的so文件有50M左右。若eta能在Android系統上使用，那將很好的解決這兩個問題。

在開發的管理方面，eta團隊似乎有很好的節奏，有靠譜的計劃。而且已經大致確定第一個release的時間，就是不知道是否會跳票了。

JVM上使用的函數式語言較常用的就是clojure和scala，eta和這兩者從實現和開發者的目標來看是比較相似的。eta是從成熟的GHC中演變而來的，再加上成熟的jvm，且成立了一個公司來開發，應該不會輕易的棄坑的，其release發布的功能完成度和可靠性應該是有保障的。

不管怎麼說，這對Haskell的發展和推廣是非常有利的，期待eta能夠在jvm上站穩腳跟，在實際的應用開發中佔有一席之地。如果能進入到Android系統的應用開發就更好了。

最後，talk is cheap, show me the code。若對eta有興趣的話，多關注eta的github，有能力的話就做些微小的貢獻吧。

本來叫 GHCVM 的, 但是後來好像說為了更好地在企業 (Enterprise) 安利不要讓人聽見 Haskell 就跑所以叫 Eta 了, reddit 相關討論: GHCVM (The GHC Haskell to JVM compiler) was renamed to ETA ? /r/haskell

至於意義, 目前應該沒有多少主流語言是搞多個backend, 不同 backend 的生態都那麼興旺的. 像Haskell那樣, target 到 native 的 GHC 是 de-facto 上壟斷的 Haskell 實現, 言稱 Haskell 其實是指 GHC, 所以 Hackage 上各種包都會用上各種語言拓展, 生態也會一家獨大. 還有, 這也不是第一次有人這麼做了, 以前在一個Erik Meijer的採訪上說他們曾經要把 Haskell 移植到 CLR/JVM, 後來不知道什麼原因棄坑了.

而像 GHCJS 或者這個改名換姓的 GHCVM, 一來在實現上會受到平台的限制, 你看 GHCJS 在 JS 這種單線程的運行時上實現整個 GHC RTS 是多麼地變態, 同樣在 JVM 上也會這樣, GC 這種跟語言相性比較相關的東西可能就不是這麼好搞了, 例如 Haskell 這種惰性的函數式語言就喜歡生成很多內存對象, 在 JVM 上可能要調下 GC 演算法才能爽, 至於 STM, LWT 這些也是挺多事的. 而且 RTS 這種東西是靠很多對語言實現, 系統了解很深的人在上面耕耘好多時間才有今天的成就, 這種新鮮滾熱辣的東西要到 production 的話還要燒不少的人力. 二來, 如果某些語言的拓展不支持的話, 某些 Hackage 上面的庫就不能用了, 我用這個庫之前還要看我的實現支不支持? 當然這個可以從包管理的角度來解決(實現+實現版本約束). 三來使用 C FFI, JS FFI, Java FFI 的庫將不能通用, 之前看到過一個例子, 前端用 GHCJS 後端用 GHC, 某部分代碼想共用, 但是 GHCJS 用的是 Javascript 的 JSSring, GHC 用的是 Text, 那人用的條件編譯來解決, 看著就覺得丑, 感覺以後 Backpack 的出現會解決這些問題.

還有 Frege 這個類 Haskell 的 JVM 語言也半死不活的, 至於這個阿三出於什麼原因搞了個公司來搞這個項目, 到底會不會黃, 會不會成功也是未知之數, 但是如果 Haskell 能夠這樣子走向"成功"的話, 我想馬丁奧德老司機會笑我們的吧

甭管怎麼樣，人家已經擼起袖子使勁幹了，我們還處在打嘴炮的階段。我在玩的時候還叫GHCVM，對Win的支持很差，在Git上聊了一下，讓他改了幾個地方，能跑，我已經很滿意了，如果能完全兼容GHC 7.10其實可以拿來玩玩。先不管能否用於工程實踐，這個項目首先就很有趣味。

這不是在山寨 Haskell，這根本就是 Haskell 啊：

-- 連 Module 名稱都完全一樣 import Control.Concurrent.STM

這代碼完全能在 GHC 下面成功編譯運行！

網站主頁上隻字未提 Haskell ，Github上寫道：

The Eta Programming Language, a dialect of Haskell on the JVM……

然後文檔：Eta FAQ - Will Eta be compatible with GHC 8?

……

PL 界的山寨之風已經從 Lisp 轉向 Haskell 了嗎？啥時候輪到 Idris？

看了首頁的幾個圖，這難道不是Haskell嗎（

突然想說幾句。。，，這個學期學完編譯原理後，我只能說，，直接從 ghc 的後端下手，會不會好一點，，，，多少年前，說是 Haskell 要上 .net 然後，，現在只有 F#，，

.net 與 jvm 這兩大「託管」平台，上跑的都是 OO 的語言，，Haskell 這種只有函數式的語言，，啊

這不是就是target jvm 的Haskell嗎？還是殘廢版

據說（來源請求，能吃嗎？）有能把LLVM IR編譯到jvm的工具，我在想GHC或許可以直接用這玩意，雖然我沒試過

嗯，前幾天正好在看vert.x上pure fp languages support

具體到jvm上的話，其實無非兩個比較主流的lisp和haskell

前者就是clojure後者就是eta了

就跑去跟eta group建議做上vert.x的language support

對方回復說：他們正在做fiber，嗯，你可以認為這是eta版的協程

等這個完成之後，就考慮將該理念export到vert.x上去

哇啦，多好啊，看著各個新生軟體產品互相支持和幫助

開源生態這樣才能真正發展起來嘛

這裡說一下vert.x上的fp語言的支持

在2.x版本上，有一個clojure的語言支持

只是fp畢竟還是受眾少了點，所以到了3的時候，就不太容易找到人來貢獻

原作者也忙

但是vert.x對於languages是unopinioned

並不排斥任何一個語言，只是盡量提供一個選擇給用戶，具體的使用，由用戶本身決定

所以clojure在2上的表現，提供了一條，就是封裝成function是可以直接在verticle中運行

其實verticle中每次都要override一下start方法也挺煩的

直接上來就是一堆的func依次執行下來就行了，這一點腳本就做得不錯

而且因為api都是code gen生成的，所以其實eta和clojure兩者，得其一便可打開這一塊市場

同時這對於fp語言來說也有好處

在vert.x這個大的結構下，可以嘗試著使用這些語言

要不然上來就跟用戶說要革命，要造反，要幹掉java，那這麼大的風險，誰敢輕易嘗試？

但是上來跟用戶說，沒有關係嘛，你可以在verticle也就是組件這個層面使用一個新語言

那用戶接受度是不是就高很多了？kotlin就是這麼在vert.x用戶中流行開來的

現在用kotlin的，除了android developers其它就是vert.x developers了

從比例上說，應該vert.x developers用kotlin的比例應該更高一點

之前群里有萌新發問：為什麼你們都能這麼快滴用上新的技術呢？

有架構師回答說，因為我們是polyglot，這就是polyglot開發的優勢所在

對於新的特性和技術，我們可以在不影響現有代碼的基礎之上，輕易地，幾乎無成本地嘗試

一旦成功，便可馬上投入生產，最壞結果就是我搞不定，我不用嘛

回去用java，項目連maven依賴都不用刪，換個文件夾就是了

但是如果成功，馬上就可以帶來生產上的benefits，為什麼不？

具體結構可以參考專欄文章：Vert.x的一個常見問題以及多語言制霸環境配置

希望將來有一天我們能儘快在vert.x上見到eta，已經有些躍躍欲試了

雖然kotlin用得挺開心，但是還是覺得class有些啰嗦

haskell和lisp那種一行一下子捅到底的寫法讓人有些羨慕

一般編程比賽，寫最快的一般都是haskell程序員

當然這個過程還木有開始，各位可以幫忙推進這個進程通過點贊的方式，請點贊該issue：

Vert.x Support · Issue #572 · typelead/eta

ghc的一個JVM後端，感覺挺靠譜，但是jvm和ghc的應用場合幾乎完全重疊，唯一的用處可能是和現有的java代碼無縫結合吧

很沒前途啊，ghc壟斷這麼多年了都…

大家都編譯器擴展全開，你弄一個不完美滋磁擴展的，就很坑，所以這個項目雖然改名了，但骨子裡還是半個Haskell……

沒救。

如果傍上jvm的大腿的話，那還勉強可以，但沒卵用啊，Haskell的庫都不要了嗎？

結論: 只是寫的爽，但是拿來寫業務邏輯(jvm常見應用場景)就不見得了。

made in india，by 一個奇怪的公司

所以是改的ghc加java ffi？