像Python一樣易用、擁有C的速度和Ruby的靈活的Julia該怎麼用？其它頭條網

像Python一樣易用、擁有C的速度和Ruby的靈活的Julia該怎麼用？

導讀：Julia 1.0 正式版發佈已過去一週多，官方表示 1.0 版本積累了富有野心的程序員們的十年心血。Julia 的開發人員在 Reddit 上參與了 AMA（Ask me Anything）你問我答的活動。他們回答了社區關於該語言創建，成長的一些問題，並透露了一些內幕消息。

來源：開源中國（ID：oschina2013）

Julia 可以看作是一門集眾家之所長的編程語言，在首次公開時開發團隊就已明確其需求：

我們想要一種擁有自由許可的開源語言，同時擁有 C 的速度和 Ruby 的靈活。我們想要一種同像性語言，有像 Lisp 這樣真正的宏，也有像 Matlab 這樣的淺顯熟悉的數學符號。我們想要一門像 Python 一樣可用於通用編程，像 R 一樣易於統計，像 Perl 一樣自然地用於字符串處理，像 Matlab 一樣強大的線性代數，像 shell 一樣擅長將程序粘合在一起的語言。它簡單易學，卻能讓嚴苛的黑客為之傾心。我們希望它是交互式的，具備可編譯性。

私信小編007即可獲取數十套PDF哦！

編程語言排行榜每月都有，排名前 10 常見 Java，JavaScript，Python，PHP 和 C＃等，大家已不足為奇。但是在 RedMonk 的語言排行榜中，開源編程語言 Julia 成功引起了大家的注意，連續四個季度增長（52,40,39,36），本季度成功升至第36位。

與此同時，Julia 的開發人員在 Reddit 上參與了 AMA（Ask me Anything）你問我答的活動。 Jeff Benzanson，Stefan Karpinski，Alan Edelman，Viral B. Shah 和 Keno Fischer 回答了社區關於該語言創建，成長的一些問題，並透露了一些內幕消息。

先來介紹一下 Julia 開發團隊中參與本次 Reddit AMA 活動的主要成員。

Jeff Bezanson(JeffBezanson)：編程語言愛好者，一直專注於 julia 的子類型(subtyping)、分派(dispatch)和類型推斷系統(type inference systems)。讓 Jeff 完成在麻省理工學院博士學位（關於 Julia)）的是一個與 Julia 相關的 issue(#8839)，對該 issue 的修復於2015年與 Julia 0.4 一起發佈。他在 Alan 的最後一家創業公司 Interactive Supercomputing 遇到了 Viral 和 Alan。
Stefan Karpinski(StefanKarpinski)：在加州大學聖巴巴拉分校攻讀計算機科學與技術專業，運用數學技術分析計算機的網絡流量。Stefan 是 Julia 標準庫大部分內容的作者，也是 Julia 軟件包管理器 Pkg 的三次迭代中每次迭代的主要設計者。
Alan Edelman(AlanEdelman)：Alan 是麻省理工學院的數學教授和計算機科學與人工智能實驗室的成員，他也是 Julia 公司的首席科學家，Alan 不僅喜歡解釋什麼是 Julia，還喜歡 Julia 看起來如此簡潔而又如此特別。
Viral Shah(ViralBShah)：Viral 於2007年在加州大學聖巴巴拉分校獲得 CS 專業博士學位，但隨後於2009年回到印度（同時也開始參與 Julia 的開發），曾與 Nandan Nilekani 一起為印度政府的 Aadhaar 項目工作。他還曾經與人合著過“重啟印度(Rebooting India)”這本書。
Keno Fischer(loladiro)：Keno 參與 Julia 開發工作時還是馬里蘭州東部一所小高中的交換生，在繼續開發 Julia 的同時，他還就讀於哈佛大學，並獲得物理學碩士學位。他是 Julia 編譯器關鍵部分和許多流行的 Julia 軟件包的作者。

Q1：由於各種各樣的原因，從零開始開發一門語言變得十分困難，其中之一就是如何在無法預料多年後結果的情況下被迫做出設計決策。那麼事後看來，你做出的最好和最壞的決定是什麼？

JeffBezanson：

正如你所說的，從零開始開發一門語言十分困難，這也是我們花了幾年時間開發“實驗性” 0.x 版本的主要原因之一。大約一年左右的時間，我們會收集有關哪些有效和無效的經驗，然後進行重大的變更 —— 有時候會發生很多的變化。我們這樣持續做了7個週期，直到我們覺得真的已經可以處理問題。
最好的決定是為 Julia 開發了多分派(multiple dispatch)，並使用多分派作為編程範式。在剛開始的短期內，目標尚不明晰，多重方法和外部分派這樣的特性看起來十分酷，但我們無法知曉它的強大，以及能給我們帶來多大用處。
最糟糕的決定是把終端的所有文字都加粗 :-P 謝天謝地，我們現在已經解決了這個問題。

loladiro：

有時候，我很驚訝看似微小的功能會改變語言的使用方式。
在第一個 JuliaCon 大會之後的黑客馬拉松中，Tim Holy 和我實現了一個名為生成函數(generated functions)的功能（當時的階段函數 staged functions），它基本上是一個回到編譯器內的鉤子，可讓你根據參數的類型生成代碼。
我想要它用於我的 C++ 包（基本上允許 julia 充當 CC++ REPL 的角色），而 Tim 希望它能加速數組。如今，它不再用於數組，因為編譯器已經改進到足以使其不必要，但它是 Cassette.jl 的基礎，這是常見的非標準(non-standard)執行框架 —— 我們計劃用於從調試到自動微分(Automatic Differentiation) 的所有內容的框架。

Q2：普遍來說，開源開發者們費力不討好的工作並沒有得到該有的讚賞。所以，首先感謝你們為 Julia 付出的努力！我的問題是：多年以前，我感覺到 Julia 擁有很強的戰鬥力 —— 替代 R 和 Python 以將其作為用於數據科學的語言。但最近我感覺到這種勢頭有所放緩。你們是否同意我的看法，如果是的話，你們覺得重燃這種熱情需要怎麼做？

loladiro：

我不會像以前一樣使用“戰鬥”之類的詞語來描述我們和 R 或 Python 之間的關係。我們通過與像 PyCall.jl 和 RCall.jl 這樣的集成，以及使用 Jupyter notebooks 一起進行開發，與他們有很好的兼容性。我認為各自都有足夠的空間。
關於數據科學這方面，在與其他一些數字應用的領域相比，我承認 Julia 確實是稍有落後。但 1.0 版本，我們嘗試做了很多底層的基礎工作來改變它。使用 1.0 版本，我們的編譯器支持高性能的缺失值
(https://julialang.org/blog/2018/06/missing)，這是 Julia 數據科學社區呼聲的請求之一，所以我也希望使用者能充分利用它，因為這是一項耗費了我們大量付出的工作。
在軟件包生態系統方面，像 Queryverse.jl 這樣的元軟件包(meta-packages)開始確保在一個統一的軟件包中提供所有不同的功能。還有 JuliaDB.jl，如果你碰巧擁有非常大的數據集，可以將其視為 pandas 的分佈式核心替代方案。儘管如此，我認為 Julia 的未來非常光明，特別是現在核心語言特性已經穩定，我們可以將更多的注意力集中在核心生態系統建設上。

Q3：你們是否認為在科學計算領域 Julia 可以取代 Python？

我正在研究機器學習，主要使用 Python 進行開發。一年前我曾嘗試過使用 Julia，而且我很喜歡它，但問題是我在 Python 及其庫的生態方面投入了大量的精力和時間（我也討厭 MATLAB 用於轉置的運算符）。你們打算如何說服開發者切換到使用 Julia 進行開發？是否打算將 sklearn 和 pytorch 這些流行的庫移植到 Julia。

JeffBezanson：

我一直記得 Steve Martin 的一句話：“你要好到讓人不得不注意你”。
在生態系統方面，Julia 的優勢就是，它的庫由純 Julia 編寫，而不是使用 C 或者 C++。這給我們帶來許多便利。用 Julia 開發靈活，高性能的庫非常容易。所以，功能方面也會慢慢趕上來的。

StefanKarpinski：

很多年以前，我想許多人都不會相信 Julia 包的生態系統會發展到如今的狀態。在許多領域 Julia 生態系統都做得很好，如，優化，微分方程，線性代數，數值分析等。這使得我們能在短時間內趕上並超越其他生態系統。
Julia 已經有了 OpenMP 風格的循環多線程，我們已經準備好合併一個拉動請求，將任務的 M：N 映射實現到硬件線程上，這將使 Julia 的線程系統與 Go 類似，但我們會將它的計算性能調高而不是用於編寫併發服務器（不過你也可以這樣做）。

Q4：作為一名 CS 專業的學生，你們是否可以告訴我學習 Julia 而不是業內已經普遍使用的其他任何語言的理由？我應該在什麼類型的項目中使用 Julia？

JeffBezanson：

我可以告訴你的是，julia 可以讓你接觸到異常廣泛的編程語言。你可以憑藉良好的性能來操作位和字節（並查看彙編代碼），然後還可以進行更高級的（相對於彙編的底層）編程，宏和麵向對象的設計，它們全都可以組合在一起。開發者會經常需要切換編程語言來完成不同類型的任務，Julia 程序員針對不同的任務使用不同的技術和風格，但保持在同一種語言中進行開發。

StefanKarpinski：

補充一下 Jeff Bezanson 提到的“查看彙編代碼”
當然，在任何編譯型語言中都是如此，但在 Julia 中這十分容易：

可以看到，Julia 的這種容易程度完全不同 —— 我從來都不想費心去看C中的彙編代碼，因為這樣做很痛苦，但我一直在看 Julia 彙編代碼，因為它的可讀性很好，而且我知道很多其他代碼也是如此。這既是一種學習工具，也是指導整個生態系統實現卓越性能的一種方式。

Q5：是否有計劃為機器學習和 AI 工具包創建一致的環境？也許像 sklearn for Python 這種？目前看來，Julia 的生態系統仍然比較分散，大多數軟件包未能兼容 Julia 1.0。所以，Julia 的路線圖是什麼，對於項目的將來，你們是如何設想的？

ViralBShah：

社區非常關注 Julia 對 AI 的所有合理用途，但重點不是創建另一個框架，而是確保 Julia 可用於機器學習。這幾乎可以歸結為兩件事：對自動微分(Automatic Differentiation)提供很好的支持，以及對硬件加速器上的原生代碼生成提供很好的支持（主要是 GPU，但也有越來越多的 TPU 和管道中的各種新東西）。
在 JuliaCon 大會上，Jarrett Revels 宣佈了 Cassette.jl 和 Capstan.jl。有了這些軟件包，我們現在有了在整個 Julia 應用程序上進行 AD 操作的通用方法。
CUDANative.jl 和相關的 GPU 軟件包也為我們提供了在 GPU 上運行 Julia 應用程序的通用方法，而底層的重構可以輕鬆定位 TPU 和其他專用處理器。隨著所有這些項目在 1.0 版本趨於穩定，我們認為 Julia 已經成為 AI 研究人員和用戶值得關注的語言。
同時，我們有 Mike Innes 開發的 Flux.jl 和 Deniz Yuret 開發的 Knet.jl ，兩者都提供了重要的 AI 功能。目標是實現無框架(Framework-less)AI。只需直接編寫 Julia 代碼，我們就能對它進行微分操作，將其粘貼到優化器中，在 GPU 上運行 —— 無需新的編程模型（如編寫計算圖一樣），或重新實現所有庫的框架。

Q6：當 Julia 能夠處理矩陣操作(matrix operations)時，你是否認為大家仍然需要購買 Matlab 許可證？

loladiro：

這取決於目前你在進行怎樣的開發工作。據我觀察，更多的開發者是從定製遺留下來的系統或 C++ 進行遷移，而不是 Matlab。尤其是如果 MatLab 非常適合你的話，根本沒有理由要轉換。如果你現在要開始一個新項目，Julia 可能會是一個不錯的選擇，當然其他語言也可能是，比如說 Python。但現在已經沒有什麼理由要選擇 MatLab 來開始一個新項目了。

Q7：首先，我要感謝你們創建 Julia 這樣了不起的項目。對我而言，觀看這門偉大的語言如何演變是一個了不起的經歷。如果你們方便回答的話，我有三個問題：

你能描述一下你們的工作日嗎？語言開發者的日常如何？
例如，Keno 成為 Julia 編譯器的主要開發者意味著什麼？
現在，在桌面端方面，有關 Julia 的下一個重大決定是什麼？你對此有何看法？
除了 Julia 之外，你最喜歡的編程語言是什麼？

loladiro：

1.我覺得我們的工作日和其他任何開發者的並無二異，主要區別可能在於在公開場合完成了多少溝通方面的工作。我一天的開始通常花在處理 GitHub issue、電子郵件、交流等這些內容上。之後，我通常會有一個長期持續進行的項目（過去六個月的大部分時間都在重新設計優化器來處理新的迭代協議，和對新的缺失數據的支持），以及需要我處理的一些高優先級錯誤。然後是各種電話和會議。例如，每週四，我們都會進行一個稱為"triage"的電話會議，我們會在這裡討論需要處理的最緊急項目、什麼事情影響了發佈新版本，並且通常會嘗試對陷入困境的事情做出決策。這些電話溝通可能非常激烈（曾經試過持續了六個多小時）。
2.每天都有很多設計方面的決策要確定，但我認為即將到來的最大領域是多線程。我們正在添加對多線程調度協同例程的支持，並充分利用這一點，因此我們必須弄清楚並行的各個方面內存和執行模型。
3.我並沒有真正最喜愛的編程語言，我認為我們可以通過幾種語言來取長補短。例如，我真的想對受限制的內存所有權模型（在各種情況下允許更積極的優化）做一些事情，而 Rust 開發者顯然已經在那裡做了很多思考。當然我們不能完全複製他們的設計，因為我們的用戶有不同的期望，但我仍然希望我們可以做些什麼。

Q8：說說 Julia v2.0 的開發計劃。

loladiro：