2011-08-09 46 views
7

在過去的幾周裏,我一直在學習和嘗試Clojure和Erlang。根據我的理解,這兩個問題都可以解決相同類型的問題 - 但是 - 採用不同的方法。如果這是正確的,那麼Clojure對於實時系統(如聊天應用程序或自動收報器工廠)來說是否可行,就像Erlang所說的那樣?實時功能?

+3

聊天應用程序和股票工廠軟實時,這意味着任何語言都可以。 –

回答

6

兩個地址的併發編程,雖然在不同的環境:

  • Clojure是在共享內存並行編程真的很好。哪裏有很多線程都在單個大塊內存(堆)上工作,他們需要協調對該內存中共享對象的訪問。
  • Erlang非常擅長分享分享分佈式計算其中進程需要能夠在多臺計算機上運行並在獨立內存空間上運行。它們不協調對對象的共享訪問。

這兩個系統都是「軟實時」,非常適合聊天和控制系統,但它們都不適合具有實時實時要求的系統。

+0

感謝您的解釋。作爲一個後續,從我迄今讀過的Erlang吹捧的事實是,它的進程(線程)管理不依賴於操作系統,從而以某種方式使其更加高效/有效。你有這方面的經驗嗎? – kin1

+0

由於能夠通過網絡直接管理功能,erlang在異構網絡上非常有效,只要您可以通過單獨的消息來完成這項工作 –

7

Clojure而言,它可以提供與底層Java VirtualMachine一樣多的實時功能。

CAN使用JVM創建硬實時系統,但這必須超越Clojure提供的語言語法。

根據您的實時性要求,它看起來像你將需要調整JVM(這裏是一個很好IBM Works article或使用特定的JVM像Fiji JVM

關於厄蘭,已經有一個相關questions on SO

聊天和股票植物應用程序可以用兩種語言來實現,但我個人懷疑它會更容易使用Clojure部署,尤其是看着雲報價(Heroku)和定期託管服務。

1

是的,對於(軟)實時應用來說,Clojure是一個非常可行的選擇。

基本上可以獲得與JVM上任何其他功能相同的實時性能。由於人們將JVM用於實時交易平臺(例如These guys),因此我確信它可以用於聊天或股票代碼。

Clojure是爲訪問共享狀態高併發應用特別好,因爲它有一個非常漂亮model of Software Transactional Memory,隨着大量線程/大批覈秤特別好。我相信在Rich Hickey的某個視頻中展示了一個併發的Clojure應用程序,這個應用程序在768內核的Azul系統框中沒有任何問題。

您可以將此與Erlang進行對比,Erlang專爲高度分佈的演員設計,該演員不共享狀態。這爲Erlang應用程序提供了跨羣集機器的巨大冗餘和可擴展性,但每個進程都可以管理它自己的獨立狀態。