Julia有什麼不好地方？缺點是啥？- viralin

banq發表於2021-07-27

這篇文章是關於 Julia 的所有主要缺點。其中一些只是對我特別不喜歡的事情的抱怨，這樣的帖子必然是主觀的。例如，有些人認為 Julia 缺乏 Java 風格的 OOP 是一個設計錯誤。我不知道，所以這篇文章不會涉及。Julia 是我最喜歡的程式語言。更重要的是，也許我是一個狂熱的粉絲。
 

編譯時間延遲
您瞭解 Julia 的第一件不好的事就是它沒有響應。你開啟你最喜歡的 IDE，啟動一個 Julia REPL，開始輸入......並在任何文字出現之前看到明顯的延遲。就第一印象而言，這並不是很好，尤其是對於一種因其速度而受到吹捧的語言。
內部發生的事情是 Julia 正在編譯其 REPL 所需的程式碼以及它與您的編輯器的整合。這種“執行時”編譯會導致我們稱之為編譯時延遲的延遲。因此，如果我們在新的程式碼中提取從外部包效果更大：使用包一個小指令碼BioSequences，並FASTX可能有2秒的延時，即使計算本身需要微秒。
它仍然可能變得更糟。在 Julian 中，延遲通常被稱為 TTFP: Time To First Plot。圖形繪圖成為這個問題的典型代表，因為繪圖涉及大量程式碼，但工作量相對較少。匯入Plots和繪製最簡單的線圖需要 8 秒。
我聽說過一些組織的程式碼庫在 Julia 中，啟動一個 Julia 程式並載入他們的包需要 5 分鐘。
這個問題從根本上是無法解決的，因為它是在基本設計級別上內建到 Julia 中的。
  

記憶體消耗大
這個很容易證明：

$ /usr/bin/time -f "%M" julia hello_world.jl
Hello, world!
148724

一個 hello-world 指令碼大約需要 150 MB 的記憶體消耗。Julia 的執行時間是巨大的——這些兆位元組不僅被 Julias 編譯器使用，而且它顯然預先分配了 BLAS 緩衝區，以防萬一使用者想要在他們的 hello-world 指令碼中乘以矩陣，你知道。忘記延遲吧，150 MB 的後臺消耗完全排除了將 Julia 用於除了在 PC 或計算叢集上執行的應用程式級程式之外的任何事情。對於其他任何東西，無論是移動、嵌入式、守護程式等，您都需要使用其他東西。
想想 Electron 因浪費資源而受到的所有仇恨。在這方面，每個Julia 程式都與 Electron 處於同一範圍內。用 Julia 編寫的命令列計算器比 2003 年的影片遊戲“命令與征服：將軍”消耗更多的記憶體。
 

Julia 無法輕鬆整合到其他語言中
Julia 龐大的執行時間的另一個後果是，從其他語言呼叫 Julia 變得很煩人。如果您的 Python 指令碼需要依賴 Julia，則您需要預先支付：延遲和150 兆位元組。
將其與 C 之類的靜態語言進行比較，您可以將 C 庫編譯為其他程式只需呼叫的二進位制檔案。Julians 通常對 Julia 社群中大量的程式碼共享和程式碼重用感到非常自豪，但值得注意的是，這種共享在語言障礙上突然停止：我們可能能夠在 Julia 中使用 Rust 庫而不會產生摩擦，但是如果可以避免的話，沒有人會使用 Julia 庫。所以如果你想編寫一些普遍使用的庫，你最好使用靜態語言。
 

弱靜態分析
靜態分析很有用。但是為了確保程式的正確性，無論如何您都需要測試，這些測試將捕獲絕大多數編譯時錯誤。你在動態語言中失去的小安全性不僅僅是由節省的時間彌補的，你可以用它來編寫更好的測試。
當您可以安全地重構時，靜態分析為大型專案提供的生產力靴子，因為如果您做錯了什麼，您會立即知道。
 Julia在靜態分析和安全方面介於 Python 和 Rust 之間。您可以為函式新增型別註釋，但錯誤仍然在執行時出現，Julia 的Linting和靜態分析正在慢慢出現和改進，但與 Rust 相比，它們只能捕獲一小部分錯誤。在編寫型別在執行時大部分時間不確定的通用包程式碼時，他們不能做太多的型別分析。
Julia 中靜態分析的另一個問題是，有很多程式碼根本無法進行靜態分析。根據靜態分析器，您可以擁有一個 Julia 包，其動態樣式會導致大量“問題”，但它仍然可以正常工作。如果您的包依賴於這樣的包，您的靜態分析將充斥著源自第三方程式碼的誤報。
批評動態語言沒有靜態分析是否不公平？
 

核心語言不穩定
Julia 於 2018 年釋出了 1.0，並且從那時起就一直致力於不破壞。那麼我怎麼能說語言不穩定呢？
不穩定不僅僅是破壞變化。它還與錯誤和不正確的文件有關。我在 1.0 之前就使用了 Julia，我經常遇到核心語言中的錯誤。不經常，但也許每兩個月一次。我不記得曾經在 Python 中遇到過錯誤。
如果您對此表示懷疑，請檢視標記為 bugs的未解決問題。
我不認為這是因為 Julia 開發人員粗心，或者 Julia 沒有經過很好的測試。這只是不斷發現錯誤的問題，因為 Julia 是相對年輕的軟體。隨著 1.0 之後的成熟和穩定，錯誤數量已經下降，並且在未來還會繼續下降。但在此之前，不要指望使用 Julia 時會有成熟、穩定的軟體。
 

生態系統不成熟
Julia 作為一種年輕的、不成熟的語言的一個更重要的後果是包生態系統同樣不成熟。與擁有大量使用者和更多開發人員的核心語言相比，生態系統的建立速度更慢。
 

型別系統執行不佳
在 Julia 中，型別可以是抽象的或具體的。抽象型別被認為是“不完整的”。它們可以有子型別，但它們不能儲存任何資料欄位或被例項化 - 畢竟它們是不完整的。具體型別可以被例項化並且可能有資料，但不能被子型別化，因為它們是final最終的。
 

您不能使用資料擴充套件現有型別
在 Python 中，您不會遇到想要子類化但不能子類化的型別。你可以子類化任何你該死的東西。
 

抽象介面是非強制和不可發現的
.. 更多點選標題
 

子型別化是一種全有或全無的事情
....
 

迭代器協議太難用了
....
 

函數語言程式設計原語沒有很好的設計
直到我嘗試了 Rust 和 Julia 的Transducers包，我才真正注意到這一點，它們都比 Julia 本身更好地實現了函數語言程式設計的基礎（我指的是對映、過濾器等）。
.....
更多點選標題


 

相關文章