從誕生之日起，Julia 已經(jīng)走過了十多個(gè)年頭。

作為一個(gè)面向科學(xué)計(jì)算的高性能動(dòng)態(tài)高級程序設(shè)計(jì)語言，Julia 在許多情況下?lián)碛心芘c編譯型語言相媲美的性能，且足夠靈活。

曾有開發(fā)者盛言贊美 Julia，從速度、通用性、多重派發(fā)等多個(gè)維度出發(fā)，認(rèn)為 ??Julia 甚至比 Python 更勝一籌??。

當(dāng)然，也有人發(fā)現(xiàn)了 Julia 尚存在一些不足之處，開發(fā)者 Yuri Vishnevsky 就寫了一篇博客控訴 Julia，并表示自己在使用多年后，已經(jīng)正式停用了 Julia。

以下是博客內(nèi)容：

多年來，我一直使用 Julia 語言來轉(zhuǎn)換、清理、分析和可視化數(shù)據(jù)、進(jìn)行統(tǒng)計(jì)和執(zhí)行模擬。

我還發(fā)布了一些開源包，例如最近鄰搜索等。但不久前我停止使用 Julia 了，我也不再推薦使用它，現(xiàn)在我來闡述一下原因。

根據(jù)我的經(jīng)驗(yàn)，在我使用過的所有編程系統(tǒng)中，Julia 及其包的錯(cuò)誤率最高，我來舉例說明一下：

• 對概率密度進(jìn)行采樣會出現(xiàn)錯(cuò)誤；
• 對數(shù)組進(jìn)行采樣會產(chǎn)生有偏差的結(jié)果；
• 乘積函數(shù)可能對 8 位、16 位和 32 位整數(shù)產(chǎn)生不正確的結(jié)果；
• 將直方圖擬合到 Float64 數(shù)組會出現(xiàn)錯(cuò)誤；
• 基本函數(shù) sum!、prod!、any! 和 all!可能會返回不正確的結(jié)果。

還有一些開發(fā)者也提出了類似的問題：

• OrderedDict 可能會損壞密鑰；
• dayofquarter () 函數(shù)在閏年的情況下會出現(xiàn)錯(cuò)誤；
• 使用帶有 error bar 的數(shù)字類型時(shí)，模擬結(jié)果不正確；
• stdout=IOStream 的 pipeline 亂序?qū)懭耄?/li>
• 由于某些 copyto! 方法不檢查別名而產(chǎn)生錯(cuò)誤的結(jié)果；
• if-else 控制流程存在 bug。

我經(jīng)常會遇到這樣嚴(yán)重的錯(cuò)誤，足以讓我質(zhì)疑 Julia 中復(fù)雜計(jì)算的正確性，在嘗試新的包或者函數(shù)的組合時(shí)尤其如此。

例如，我發(fā)現(xiàn) Distance 包中的 Euclidean distance 不適用于 Unitful vector;還有人發(fā)現(xiàn) Julia 運(yùn)行外部命令的函數(shù)不適用于 substring，Julia 對缺失值的支持在某些情況下會破壞矩陣乘法，標(biāo)準(zhǔn)庫的 @distributed 宏不適用于 OffsetArrays......

尤其是 OffsetArrays 被證明是 correctness bug 的重要來源。這個(gè)包提供了一種數(shù)組類型，它利用 Julia 靈活的自定義索引功能來創(chuàng)建數(shù)組，而不必從 0 或 1 開始。

這可能會導(dǎo)致內(nèi)存訪問越界，如果你很幸運(yùn)，將導(dǎo)致 segfault;如果不幸運(yùn)，則會導(dǎo)致錯(cuò)誤的結(jié)果。我曾經(jīng)在 Julia 核心代碼中發(fā)現(xiàn)一個(gè) bug—— 即使用戶和庫作者都編寫了正確的代碼，它也可能導(dǎo)致內(nèi)存訪問越界。

我向 JuliaStats 組織提交了一些與索引相關(guān)的問題，該組織負(fù)責(zé)管理諸如 Distributions 之類的統(tǒng)計(jì)數(shù)據(jù)包和 StatsBase。我列出的問題包括：

• 存在 offset axes 的情況下，大多數(shù)采樣方法都是不安全且不正確的；
• 擬合 DiscreteUniform 分布會返回不正確的答案；
• counteq、countne、sql2dist、L2dist、L1dist、L1infdist、gkldiv、meanad、maxad、msd、rmsd 和 psnr 可能會返回帶有 offset 索引的錯(cuò)誤結(jié)果；
• @inbounds 的不正確使用會導(dǎo)致統(tǒng)計(jì)數(shù)據(jù)計(jì)算錯(cuò)誤；
• Colwise 和 pairwise 會返回不正確的 distance；
• offset 數(shù)組的權(quán)重向量訪問內(nèi)存越界。

這些問題背后的根本原因不單單是索引，還有當(dāng)與 Julia 中的 @inbounds 一起使用時(shí)，就允許 Julia 從數(shù)組訪問中刪除邊界檢查。

function sum(A::AbstractArray)
    r = zero(eltype(A))
    for i in 1:length(A)
        @inbounds r += A[i] # ← ??
    end
    return r
end

上面的代碼讓 i 從 1 迭代到數(shù)組的長度。如果將一個(gè)具有異常索引范圍的數(shù)組傳給它，就會導(dǎo)致內(nèi)存訪問越界，并且錯(cuò)誤地使用 @inbounds 導(dǎo)致程序中刪除了邊界檢查。

然而，這段代碼正是多年來如何使用 @inbounds 的官方示例。

該問題現(xiàn)已修復(fù)，但令人擔(dān)憂的是，@inbounds 很容易被濫用，導(dǎo)致數(shù)據(jù)損壞和不正確的數(shù)學(xué)結(jié)果。根據(jù)我的經(jīng)驗(yàn)，這些問題包括但不限于 Julia 生態(tài)系統(tǒng)中的數(shù)學(xué)部分。

我在嘗試完成 JSON 編碼 、發(fā)出 HTTP 請求、將 Arrow 文件與 DataFrames 一起使用，以及使用 Pluto 編輯 Julia 代碼等日常任務(wù)時(shí)，發(fā)現(xiàn)一些庫中也存在 bug。

當(dāng)我開始好奇我的經(jīng)歷是否具有代表性時(shí)，一些 Julia 用戶私下分享了類似的故事。

例如，Patrick Kidger 描述了他使用 Julia 進(jìn)行機(jī)器學(xué)習(xí)研究的嘗試：

在 Julia Discourse 上看到帖子說「XYZ 庫不 work」是很常見的，隨后其中一位庫維護(hù)者的回復(fù)說「這是 XYZ 依賴的 ABC 庫的新版本 a.b.c 中的上游錯(cuò)誤。我們會盡快修復(fù)?！?/p>

Patrick 還談到：

我記得我的一個(gè) Julia 模型訓(xùn)練失敗的時(shí)候，我非常不開心。我斷斷續(xù)續(xù)地花了幾個(gè)月的時(shí)間試圖讓它 work，嘗試了能想到的每一個(gè) trick。

最終我發(fā)現(xiàn)了錯(cuò)誤：Julia/Flux/Zygote 返回了不正確的梯度。在花了這么多精力之后，我放棄了。經(jīng)過兩個(gè)小時(shí)的開發(fā)工作，我成功地在 PyTorch 中訓(xùn)練了模型。

在討論中，其他人表示也有類似的經(jīng)歷：

@Samuel_Ainsworth：像 @patrick-kidger 一樣，我被 Zygote/ReverseDiff.jl 中的梯度錯(cuò)誤 bug 所困擾。我花費(fèi)了數(shù)周的時(shí)間，徹底動(dòng)搖了我對整個(gè) Julia AD 領(lǐng)域的信心。在使用 PyTorch/TF/JAX 的時(shí)候，我從未遇到過這樣的梯度 bug。

@JordiBolibar：從我開始使用 Julia 進(jìn)行研究以來，我在 Zygote 中遇到了兩個(gè) bug，這使我的工作減慢了幾個(gè)月。積極的一面是，這迫使我深入研究代碼，并了解到很多關(guān)于我正在使用的庫的信息。但是我發(fā)現(xiàn)自己需要花費(fèi)大量時(shí)間調(diào)試代碼，而不是進(jìn)行本職研究。

可見，Julia 的問題是如此普遍。Julia 沒有正式的接口概念，泛型函數(shù)傾向于在邊緣情況下不指定其語義，并且許多常見隱式接口的性質(zhì)尚未明確(例如，Julia 社區(qū)對數(shù)字是什么沒有達(dá)成一致意見) 。

Julia 社區(qū)有非常多有能力、有才華的人，他們用自己的時(shí)間、工作和專業(yè)知識為 Julia 的改進(jìn)做出了貢獻(xiàn)。但一些系統(tǒng)性問題很少能自下而上解決，我的感覺是開發(fā)團(tuán)隊(duì) leader 不承認(rèn)存在嚴(yán)重的正確性問題。他們接受個(gè)別孤立問題的存在，但不接受這些問題背后的根本模式存在錯(cuò)誤。

例如，在 Julia 機(jī)器學(xué)習(xí)生態(tài)系統(tǒng)還不夠成熟的時(shí)候，該語言的一位聯(lián)合創(chuàng)始人就興奮地談到在自動(dòng)駕駛汽車生產(chǎn)中使用 Julia：

另一位聯(lián)合創(chuàng)始人曾表示 Julia 有一個(gè)很大的優(yōu)勢是利于代碼復(fù)用：

我認(rèn)為最重要的不是 Julia 是一門多棒的語言，而是它的設(shè)計(jì)讓實(shí)現(xiàn)代碼復(fù)用的能力提升了一大截。在 Julia 中，使用者可以有效地聯(lián)合使用由一個(gè)人編寫的通用算法和由其他人編寫的自定義類型。語言設(shè)計(jì)者不應(yīng)該仿照 Julia 的所有功能，但他們至少應(yīng)該理解為什么它會如此有效，并且能夠在未來的設(shè)計(jì)中實(shí)現(xiàn)類似級別的代碼復(fù)用。

從社區(qū)的角度看，每當(dāng)出現(xiàn)一篇批評 Julia 的帖子時(shí)，社區(qū)內(nèi)都會有開發(fā)者為其辯駁例如：

2016 年時(shí)存在這個(gè)問題，但現(xiàn)在已經(jīng)得到了很好的解決。

在 Julia 中，沒有對一致性的強(qiáng)制執(zhí)行，但泛型函數(shù)是很有效的。

Julia 當(dāng)然有 bug，但沒有一個(gè)是嚴(yán)重的。

這些說法在小范圍內(nèi)似乎是合理的，但如果一直如此會造成使用者的合法體驗(yàn)被削弱或淡化，更深層次的根本問題沒有得到承認(rèn)和解決。

憑借過去十年在編程語言和開源社區(qū)方面的經(jīng)驗(yàn)，我認(rèn)為至少在基本正確性方面，Julia 目前并不可靠，也許正在變可靠的路上。Julia 及其開發(fā)者必須重新審視和修改它的可靠性。