Julia生產環境就緒了嗎?Bogumił Kamiński的訪談

JuliaCon 2020剛剛結束,華沙經濟學院的教授和DataFrames.jl項目的維護者Bogumił Kamiński總結了Julia語言的狀態和生態系統,並宣稱Julia終於已經達到生產環境就緒

Kamiński教授的文章在Hacker News上引發了一些反響。有些評論者對Julia可視爲生產環境就緒的通用語言提出了質疑,尤其是在文檔、包、工具和支持方面。

InfoQ有幸與Kamiński教授進行了交流,以便於更好地理解他的觀點。

InfoQ:您能描述一下自己的背景以及所參與的與Julia相關的工作嗎?

Kamiński:我是波蘭華沙經濟學院的教授,主要從事運籌學和仿真建模方面的研究。

就提交的數量而言,我在Julia語言的貢獻者中排名前5%,是Julia數據生態系統的重要貢獻者,尤其值得一提的是,我還是DataFrames.jl的核心維護者。

在StackOverflow上,我是[julia]標籤下排名第二的回答者。在全職轉入學術界之前,我曾經管理數百人組成的開發人員和分析師團隊超過十年的時間,爲波蘭最大的公司和機構部署BI/DWH/數據科學項目。

InfoQ:在文章中,您的主要觀點是Julia生態環境已經達到了成熟的水平,可以投入生產環境了。您能進一步說明一下這一點嗎?是什麼阻礙了Julia在生產環境採用?移除這些障礙最重要的進展又是什麼?

Kamiński:下面的這些定義對於我將Julia理解爲生產環境就緒是至關重要的。

我將其定義爲:具有達到穩定水平的語言和核心包,不會“每六個月”就發生重大變化。這意味着,在開始新項目的時候,我們可以放心地預期,在一個較長時間(幾年)內所有的事情都會正常運行。

在過去,這是一個主要的問題。語言和核心包會非常頻繁地變更其API,一年前創建的教程現在如果不進行更新的話就無法正常運行。對於正在開發中的語言和生態系統來講,這是一種正常的狀態。現在,我看到事情正在發生着明顯的變化,尤其是核心Julia語言,但是類似的事情還在包生態系統中存在。

這並非意味着新的包沒有處於“持續變化”的狀態中,但這是在所有包生態系統中都能看到的現象,因爲新事物總是變化得很快。

除此之外,包管理已經相當成熟,我要說在該領域它是目前最棒的。

這意味着付出了很大的努力使一切“正常運行”,尤其是對於包含二進制依賴的包。相反,在幾年前,如果你安裝一個包的話,它可能會因爲一些外部依賴沒有編譯而失敗。所以,我們必須要手動調整包的源碼,這樣才能使其正常運行,當然前提是知道該怎麼做,這並不總是那麼顯而易見的。

尤其是,自從Julia 1.5以來,我們就有可能實現Julia無縫的企業級部署。在其之前,會出現一些問題,這是由於它所採用的用來同步GitHub的包管理協議經常會因爲企業環境中的防火牆設置而崩潰。

爲什麼這很重要呢?我們可以很容易地“交付”一個Julia項目,並且預期任何環境中的任何人都能相對很容易地運行它。當然,會有一些極端情況導致無法正常運行,但是就我每天使用Linux和Windows 10的經驗來說,在這兩個平臺上都能正常運行。

如果使用Julia編寫項目的話,我們可以要麼預期有一個包能夠完成你想做的事情,要麼可以使用C或Python編寫代碼並使其能夠正常運行。在我們的博客文章中,我想要強調的是,我們已經達到了這種狀態。以本週正在做的事情作爲樣例,Julia有一個非常棒的LightGraphs.jl包,用來進行圖處理,但是我的合作者使用Python並且更喜歡使用igraph。如下是一個使用igraph的樣例(改編自igraph的Python教程):

import igraph as ig
g = ig.Graph()
g.add_vertices(3)
g.add_edges([(0,1), (1,2)])
g.add_edges([(2, 0)])
g.add_vertices(3)
g.add_edges([(2, 3), (3, 4), (4, 5), (5, 3)])
g.pagerank()

現在,你可能想問同等功能的Julia代碼怎麼實現。如下所示:

using PyCall
ig = pyimport("igraph")
g = ig.Graph()
g.add_vertices(3)
g.add_edges([(0,1), (1,2)])
g.add_edges([(2, 0)])
g.add_vertices(3)
g.add_edges([(2, 3), (3, 4), (4, 5), (5, 3)])
g.pagerank()

正如我們所看到的,它是基本相同的。當然,並不是所有的場景都這麼簡單,比如,Julia和Python中的字典有不同的語法,但這是事物運行的通用規則。我們甚至可以使用tab補全和直接訪問docstrings。

在實踐中,這意味着什麼呢?如果你正在做一個項目的話,那麼你不會陷入這樣的思考:“我可以使用Julia嗎,在未來的三個月內,我可能在項目裏會使用一些Julia還沒有提供的東西?”但是,你應該知道,“我可以相對安全地使用Julia,因爲目前很多通用的包已經就緒,而且即便是缺少了某些東西,我也可以通過其他語言來使用它,不管是C/Python/R,還是其他語言,這都不會太痛苦。”

另外,作爲生產環境就緒的一部分就是PackageCompiler.jl,藉助它我們可以創建“一組文件所形成的應用,其中包含一個可執行文件,它可以發送到其他機器上並運行,在目標機器上並不需要安裝Julia。”我認爲它並非生產環境就緒的必備特性(很多被視爲生產環境就緒的腳本語言都沒有提供這樣的選項),但是在很多場景下,具備這樣的特性是很棒的。

現在,我澄清一下,哪些是“生產環境就緒”定義中不應該包含的內容。我並不認爲Julia是最適合任何項目的語言。每種語言都有其自己的定位,Julia的定位是高性能計算/數據科學(或者你所喜歡的稱呼)。如果你希望獲得一個佔用空間非常小的二進制文件,那麼Julia肯定不是首選的語言。如果你想爲Android開發應用,那麼Julia肯定也不是適合的語言。

我相信如果你想做一個Julia非常適用的項目,想要將其投入生產環境,很可能需要滿足一些通用的需求。這些需求只是爲了能夠讓你的核心特性能夠與代碼所部署的生態系統的其他部分能夠很好地協作。而且,我相信Julia已經達到了一個很容易實現的成熟等級,不管是現有的包還是與外部工具集成,在Julia中都是非常簡單的。

InfoQ:從Hacker News上的一些評論來看,您的聲明似乎有些爭議,尤其將Julia作爲一種生成環境就緒的通用語言方面。您想補充一些其他的觀點嗎?

Kamiński:引用一下我在博客文章開頭的地方所寫的內容:

“迄今爲止,我已經花了20年的時間在企業環境中部署與數據科學相關的項目(那時還不叫數據科學,但是我們已經在訓練神經網絡進行預測),我有很多同事都對企業級軟件開發有很深的理解。”

這就是我這篇博客文章的框架,也就是從事數據科學,不是在“你的後花園”或“學術性研究實驗室”,而是在“商業化環境”。正如我在前面所述,無論是我,還是Julia相關的任何開發人員,都不認爲它是開發任何類型項目的“一站式方案”。

如果你看一下Julia開發者調查報告,在第28頁,很明顯,人們正在使用Julia進行計算,這是我相信Julia已經生產環境就緒的領域。

現在,關於像文檔、包、工具和支持這些方面,當然這是應該進行改善的,並且我相信也將會得到改善。我同意像R/Python/Java這種更成熟的生態系統在這方面覆蓋得更好。例如,作爲DataFrames.jl的維護者,我可以告訴你,最近大多數的PR都是文檔相關的。但是,在這裏我不會低估Julia社區。一般來講,如果你有問題,並且發佈到StackOverflow、Julia Discourse或Julia Slack上的話,通常幾分鐘之內就會得到答案,最多不超過幾個小時。這裏有一個這種情況的真實故事:人們通常對此反應很迅速,缺陷很快就能修復。

如果讓我指出Julia的一個主要的亮點的話,那就是在普通開發者社區中有足夠熟練掌握該語言的人。我能理解產品負責人/項目經理的感受,那就是擔心一旦開始使用Julia之後,面臨找不到足夠的人來完成項目的風險。但是,在這方面,我相信情況正在不斷改善。JuliaCon 2020有超過兩萬人蔘加。另外,網上已經有很多免費的資源

InfoQ:除了關注Julia是否已經生產環境就緒,或者它適用於哪些領域,在您看來,該語言的主要優勢是什麼?您認爲它是Python、R或其他語言的替代方案嗎,或者至少在科學計算和數據科學領域是這樣的嗎?

Kamiński:在這裏,我覺得最好引用一下Julia開發人員調查的第8頁到第11頁。我主要討論第8頁中最重要的三件事:

  • 速度:這方面相對比較簡單直接。任何成熟的包,如TensorFlow或PyTorch,都需要高性能,它們大多數都是使用C++編寫的。而Python只是對C++核心的一層薄薄的封裝。現在,再看一下Flux.jl或Knet.jl,它們本質上是使用純Julia實現的。因此,底線就是,如果你需要代碼快速運行,並且想利用高級語言的優勢的話,那麼Julia是一個非常自然的選擇。此外,如上所述,如果你想使用非常快的外部庫的話,那麼這相對是非常易於實現的

  • 易用性:它包含很多方面,但是根據我的經驗,如果掌握了Julia原則,在進行數值計算的時候,與R/Python相比,它的語法和設計都很不錯。Julia語言就是圍繞支持這些任務而設計的。這不僅僅是語法的問題,它還可以是事情隱形發生,我們必須顯式處理的一種可選方案(比如廣播)。根據我的經驗,這使得Julia代碼易於維護,而且編寫良好的代碼在很大程度上本身就是文檔化的。

  • 代碼開源且可修改:這方面有兩個維度。首先,大多數的Julia包都是MIT協議的,在企業環境中,這通常是很受歡迎的。其次,大多數包都是使用Julia編寫的,如果你不喜歡某些方面的話,可以自行修改(這比在R/Python中要容易得多,在這些語言中通常你需要修改的內容都是使用像C、C++、Fortran等語言編寫的)。

人們通常會問我是否將Julia視爲R/Python的替代方案。在這方面,我的想法是這樣的:

  • 如果正在進行需要高性能的複雜計算,那麼我肯定會選擇Julia作爲工具完成項目中這部分功能的開發。

  • 如果有一個非性能關鍵性的新任務,那麼可以選擇你最熟悉的任意語言(如果你在上述的第一點上做過很多工作的話,就像我這樣,那麼你可以安全地選擇Julia)。

  • 如果你有很多遺留的R/Python代碼並且對此感覺還比較滿意的話,那麼可以繼續堅持下去,並且要記住,如果在裏面有一些性能關鍵性的內容的話,那麼它們可以相對簡單地採用Julia進行重寫,然後與原有的代碼庫進行集成(我做過很多類似的項目)。

InfoQ:對於Julia的演化,您的觀點是什麼呢?

Kamiński:首先,我要說,我同意你在這個問題中所隱含的意思:這將是一個“演進”,而不是“革命”。Julia的設計已經被證明是健壯的,我不認爲它會有顛覆性的變化,而是在很多領域會看到漸進式的改善。

如果具體說明幾個主要的維度的話,那麼將會是:

  • 對多線程支持的改善。我認爲這對Julia核心使用場景關係重大。Julia已經爲此提供了支持,但是在這方面還有很多內容需要改善。與之類似,對GPU/TPU處理的改善也是值得期待的。

  • 編譯器延遲的改善。同樣,隨着每個版本的發佈,它都在變得更好,但是這是每個人都覺得是必須要改善的地方。

  • 提供更成熟的包管理生態系統。在這方面,我指的主要是包的質量、穩定性和文檔化,就功能覆蓋率而言,已經有成千上萬的包可用了。強調一句,我相信許多核心包已經相當成熟,但是我同意人們的意見,應該在這方面進行改善。

  • 社區的增長。我相信對Julia感興趣的人正在顯著增長,JuliaCon2020參與者數量的增加就說明了這一點。這意味着:a)如果需要的話,將來招聘高質量的Julia開發人員將變得更加容易;b)隨着越來越多的人報告問題並參與進來,這會爲Julia生態系統的質量創造一個正向的反饋循環。同時,作爲DataFrames.jl的維護者,我注意到了這樣一種轉變,那就是從來沒有參與過包“核心”開發的人正在提出issue/提交PR,並在社交媒體上討論相關的功能。

原文鏈接:

Is Julia Production Ready? Q&A With Bogumił Kamiński

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章