相比高人氣的Rust、Go，為何 Java、C 在工具層面進(jìn)展緩慢？

2022 年 Stack Overflow 開發(fā)者調(diào)查結(jié)果已經(jīng)正式公布。每當(dāng)這個(gè)時(shí)候，開發(fā)者們都有一肚子的話要吐槽或表?yè)P(yáng)，開發(fā)者 Adam Gordon Bell 也不外如是。Bell 最關(guān)注的是最受歡迎和最不招人待見的編程語(yǔ)言。我們先簡(jiǎn)單看下調(diào)查結(jié)果：

最受歡迎的高人氣編程語(yǔ)言（2022）：

Rust，Typescript，Python，Go，C#，Kotlin，JavaScript

最不受待見的高人氣編程語(yǔ)言（2022）：

Ruby，C++，Java，PHP，C

在上一次開發(fā)者調(diào)查報(bào)告時(shí)，Bell 提到當(dāng)人們喜愛一種新的編程語(yǔ)言時(shí)，大家或多或少會(huì)抱有些許偏見，即認(rèn)為新語(yǔ)言應(yīng)該拿來開發(fā)新項(xiàng)目、舊語(yǔ)言則用于開發(fā)舊項(xiàng)目。但這明顯忽略了另一個(gè)現(xiàn)實(shí)：語(yǔ)言工具本身也在不斷改進(jìn)。因此，Bell 寫了一篇文章來論述了自己的觀點(diǎn)，并將編程語(yǔ)言被喜歡的原因歸結(jié)到了工具性發(fā)展上。

以 Go 和 Rust 為例，業(yè)界關(guān)于兩者的爭(zhēng)論從未停止，但兩種語(yǔ)言的開發(fā)者工具在體驗(yàn)上非常相似：它們都非?，F(xiàn)代，無(wú)論是測(cè)試、模糊測(cè)試、打包還是校驗(yàn)，它們都能提供相應(yīng)的最佳工具標(biāo)準(zhǔn)包。Bell 認(rèn)為，Go 和 Rust 跟不受待見榜單中那些語(yǔ)言的最大區(qū)別，并不在于語(yǔ)法細(xì)節(jié)，而是工具選項(xiàng)和生態(tài)系統(tǒng)。正是如此，二者才能雙雙進(jìn)入最受喜愛語(yǔ)言名單。

Bell 認(rèn)為，隨著時(shí)間的推移，編程語(yǔ)言的工具和開發(fā)者體驗(yàn)正在改善，但這種改善在新語(yǔ)言中體現(xiàn)得更加明顯?？傮w來說，在創(chuàng)新成果出現(xiàn)之后，新語(yǔ)言會(huì)更快采用并加以標(biāo)準(zhǔn)化，最終提供超越老牌語(yǔ)言的效果。隨著這類增量的積累，曾經(jīng)的王牌語(yǔ)言就會(huì)顯得陳舊而腐朽。

“為什么不能交個(gè)朋友？”

網(wǎng)友 “crashorbit ”指出了實(shí)際開發(fā)中存在的問題?！按蠖鄶?shù)從事系統(tǒng)工作的人都是短期的承包商，他們不了解問題所在，并且在交付了一個(gè)測(cè)試不佳的系統(tǒng)后很快就離開了?？赡芎雎粤税姹究刂?、自動(dòng)化測(cè)試、文檔更新、發(fā)布工程和預(yù)期的系統(tǒng)開發(fā)生命周期的其余部分。”

crashorbit 表示，中層管理者不懂系統(tǒng)工程，高級(jí)管理人員更感興趣的是“完成”事情，而不是擁有可持續(xù)的系統(tǒng)工程實(shí)踐?！疤孤实卣f，我們很難區(qū)分一個(gè)設(shè)計(jì)良好的信息系統(tǒng)和一個(gè)基本可以工作但‘大風(fēng)一吹’就會(huì)失敗的系統(tǒng)?！?/p>

每年從事“軟件工作”的人數(shù)都以幾個(gè)百分點(diǎn)的速度增長(zhǎng)。他們中的大多數(shù)人在非常垂直的環(huán)境中工作，經(jīng)常在自己的桌面上編寫電子表格或雜亂無(wú)章的應(yīng)用程序。一些人編寫的“腳本”只是做簡(jiǎn)單的事情?；蛘呤褂盟麄儾焕斫獾摹皺C(jī)器學(xué)習(xí)”工具產(chǎn)生具有誤導(dǎo)性的結(jié)果。

“我們以這種方式創(chuàng)造即時(shí)遺產(chǎn)。沒有模塊化、沒有修訂控制、沒有部署策略，也沒有災(zāi)難恢復(fù)計(jì)劃。開發(fā)人員早已不在，更不用說系統(tǒng)工程師了。這就是我所說的‘傳統(tǒng)阻力’的意思，這就是這個(gè)行業(yè)如此緩慢的原因?！?crashorbit 表示。

開發(fā)者“fuddlesworth”表示自己所在的公司就已經(jīng)被 React 16 “困住”，因?yàn)檎麄€(gè)公司的核心 UI 組件都在使用 Enzyme 進(jìn)行測(cè)試，一旦轉(zhuǎn)變就要改動(dòng)成千上萬(wàn)個(gè)測(cè)試?！拔覀儾荒茉俑鶕?jù) React 來更新任何組件了，所以沒有 bug 修復(fù)、新特性、性能改進(jìn)等等?！?/p>

開發(fā)者“alexiooo98”則認(rèn)為，更好的工具當(dāng)然非常受歡迎，但僅憑這個(gè)并不能完全解釋為什么有些語(yǔ)言受到喜愛，而有些則令人恐懼。比如，（現(xiàn)代）PHP 有很好的工具，但令人恐懼。Python 的包管理器環(huán)境非?；靵y，然而 Python 很受歡迎。

下面是 Bell 文中關(guān)于編程語(yǔ)言發(fā)展差異的詳細(xì)描述，我們進(jìn)行了翻譯并做了不改變?cè)獾男┰S修改。請(qǐng)注意，下文中提到的創(chuàng)新跟語(yǔ)言的語(yǔ)法或語(yǔ)義無(wú)關(guān)。

我不確定這到底是好事還是壞事，但擴(kuò)展標(biāo)準(zhǔn)庫(kù)確實(shí)讓開發(fā)者無(wú)需安裝任何第三方庫(kù)，就能直接享受到 PHP、Python 和 Go 的大量現(xiàn)成功能。它們大部分都帶有 json、http 客戶端和服務(wù)器，甚至包括數(shù)據(jù)庫(kù)訪問機(jī)制。

——Amir Saeid

所謂標(biāo)準(zhǔn)庫(kù)，就是語(yǔ)言所附帶的常用內(nèi)容庫(kù)。C 有 libc、C++ 有 libcpp，但與如今常見的內(nèi)置“電池”標(biāo)準(zhǔn)庫(kù)相比，前面二位的庫(kù)規(guī)模實(shí)在小得可憐。

我有點(diǎn)記不清了，但 1991 年誕生的 Python 似乎是第一種真正擁有廣泛標(biāo)準(zhǔn)庫(kù)的編程語(yǔ)言。Java 1.0（1996 年）也附帶一個(gè)擴(kuò)展標(biāo)準(zhǔn)庫(kù)（Java Class 庫(kù)），隨后引發(fā)其他語(yǔ)言紛紛效仿。

這種無(wú)需自行構(gòu)建、又不必接觸第三方依賴項(xiàng)的便捷工具交付方式，實(shí)在是全世界開發(fā)者的一大福音。

大部分現(xiàn)代語(yǔ)言（不包括 JavaScript ）現(xiàn)在都附帶豐富的標(biāo)準(zhǔn)庫(kù)。不過，Go 對(duì)標(biāo)準(zhǔn)庫(kù)的強(qiáng)調(diào)仍然無(wú)人能及，它承諾向下兼容，而且非常關(guān)注性能和完善的具體實(shí)現(xiàn)。正因?yàn)槿绱?，Go 開發(fā)者對(duì)標(biāo)準(zhǔn)庫(kù)的依賴性遠(yuǎn)超其他社區(qū)，對(duì)標(biāo)準(zhǔn)庫(kù)也普遍更為重視。

就在標(biāo)準(zhǔn)庫(kù)成形的同時(shí)，萬(wàn)維網(wǎng)也開始迅速騰飛。事實(shí)證明，互聯(lián)網(wǎng)確實(shí)是一套出色的協(xié)作平臺(tái)。

如果我們的需求無(wú)法在標(biāo)準(zhǔn)庫(kù)中得到滿足、必須自行構(gòu)建新功能，該怎么做？Perl 通過 CPAN 推廣了全球工具包集合的概念，一切就從那時(shí)起徹底改變。公平地講，任何用過 CPAN 并為它做出貢獻(xiàn)的朋友，都能感受到它改變游戲規(guī)則的重大意義。

CPAN 于 1995 年推出（基于 CTAN），并于 2003 年達(dá)到頂峰。它的出現(xiàn)為使用軟件完成工作的人們開辟出一條新的路徑，就是將第三方組件拼接起來。現(xiàn)在，很多現(xiàn)代開發(fā)項(xiàng)目都會(huì)遵循這種模式。

從 2003 年開始，之后誕生的常用編程語(yǔ)言幾乎全部附帶某種第三方工具包庫(kù)。這股風(fēng)潮的締造者就是 CPAN，它告訴全世界：“真正的”編程語(yǔ)言，必須要有第三方工具包管理策略。

說到這里，有朋友可能會(huì)問，既然 CPAN 讓 Perl 變得更好、也讓后來的新語(yǔ)言都接受了第三方工具包管理器這個(gè)概念，那為什么之前的語(yǔ)言就沒想著亡羊補(bǔ)牢、加上包管理器呢？

其實(shí)他們有想過，但語(yǔ)言的發(fā)展一旦經(jīng)過特定階段，之后再想達(dá)成一致意見似乎變得越來越難。我不知道為什么會(huì)這樣，可能大多數(shù)人不喜歡做改變？

反正只要編程語(yǔ)言的習(xí)慣表達(dá)、基本模式和技術(shù)社區(qū)一旦建立，就很難再回頭調(diào)整了。正是因?yàn)檫@個(gè)，所以 JavaScript 有 NPC、Rust 有 crates，而 C++ 卻自己獨(dú)占 dds、cpm、conan、pacm、spakc、buckaroo、hunter 和 vcpkg。就是因?yàn)檫_(dá)不成普遍共識(shí)，所以 C++ 這邊才冒出了八種工具包管理器。

但標(biāo)準(zhǔn)庫(kù)的向后移植倒是比較順利，C++ 成功把一部分 STL 招至麾下，雖遲但到底完成了標(biāo)準(zhǔn)庫(kù)的添加。所以說，老語(yǔ)言也可以搭載工具創(chuàng)新，只是難度會(huì)更大一些。

總之，在 CPAN 之后，強(qiáng)大的標(biāo)準(zhǔn)庫(kù)已經(jīng)能幫助開發(fā)者完成大部分任務(wù)。另外，易于使用且接受直接貢獻(xiàn)的第三方工具包庫(kù)也成了標(biāo)配。沒有這兩樣，語(yǔ)言將毫無(wú)生命力。

有了第三方工具包，接下來就是用簡(jiǎn)單的方式把它們記錄下來。我遇到的最早文檔版本就是 Javadoc。它讓我能更輕松地在 Java Class 中找到自己需要的內(nèi)容：只需在 Web 上的 Javadocs 中單擊即可。之后，我們可以把 Javadoc 和 IDE 集成結(jié)合起來，快速使用自己之前從未見過的代碼。由此，探索性編碼成為了可能。

如今，Java 的 Javadocs 已經(jīng)不再是業(yè)界標(biāo)桿。Go 有 godoc，Julia 有 Documeter.jl，就連 hackage 也有很好的工具包文檔。但縱觀天下，最強(qiáng)的文檔工具還要數(shù) Rust 的 docs.rs。

我看到的一項(xiàng)改進(jìn)是，J2EE 和 Web 服務(wù)器的標(biāo)準(zhǔn)化，成就了我們今天賴以生存的計(jì)算基礎(chǔ)。Java 與 JVM 雖然做出開創(chuàng)，但我覺得它們并沒得到充分的認(rèn)可。在 Java 普及之后，開發(fā)平臺(tái)與部署平臺(tái)真正實(shí)現(xiàn)了互不干擾。如今每個(gè)人都習(xí)慣了這樣的優(yōu)勢(shì)，但在 20 年前，這絕對(duì)是場(chǎng)革命性的顛覆。

——Cédric Beust

Java 和 JVM 確實(shí)推動(dòng)了跨平臺(tái)開發(fā)的一路前行。開發(fā)環(huán)境不再需要跟生產(chǎn)環(huán)境緊密匹配。使用 JVM，我們可以將內(nèi)容編譯成 JAR，并隨意運(yùn)行在任何安裝有 Java 虛擬機(jī)的環(huán)境當(dāng)中。

后來的虛擬化和容器化進(jìn)一步拓寬了隨處運(yùn)行的道路，但 Java 確實(shí)是第一種支持這類隨處運(yùn)行工作流的主要編程語(yǔ)言。

Java 方法當(dāng)然不是完美的，首先就是 JIT 代碼的啟動(dòng)速度很慢，另外是無(wú)法輕松調(diào)用非 Java 編寫的代碼。GraalVM 聲稱能夠解決這些問題，但目前的主流趨勢(shì)仍然是提前交叉編譯。只要不包含 C 或 libc 依賴項(xiàng)，Rust 和 Go 就都能輕松實(shí)現(xiàn)隨處運(yùn)行。

但目前隨處運(yùn)行中的最強(qiáng)者似乎要數(shù) Zig，它不僅能夠輕松完成 Zig 程序的交叉編譯，還能兼容由 Clang 或 GCC 構(gòu)建的任何代碼。

有語(yǔ)言就有編譯器，其中提供大量標(biāo)記可用于靈活調(diào)用，但使用過程也是相當(dāng)麻煩。所以出現(xiàn)了 Make 和 AUtotools 這類工具。而后來的第三方工具包生態(tài)系統(tǒng)，又讓復(fù)雜度提升了一個(gè)量級(jí)。為了解決問題，出現(xiàn)了 Maven 和 pip。但與之對(duì)應(yīng)，我們又遇上了編譯器或運(yùn)行時(shí)版本不統(tǒng)一的問題，于是不同的程序就需要匹配不同的工具包版本。Python 給出了自己的解決方案，就是 pipenv、妙手 ualenv 以及 conda 之類我壓根理解不了的東西。

所有這一切讓復(fù)雜度繼續(xù)提升，導(dǎo)致新用戶幾乎跟不上節(jié)奏。因此，新的語(yǔ)言開始嘗試把這些一切集中管理起來，簡(jiǎn)化開發(fā)流程。

我想說，工具包管理和 LSP 是我編程職業(yè)生涯中見證過的，真正改變游戲規(guī)則的兩大重要因素。

——Ganesh Sittampalam

就像內(nèi)置“電池”標(biāo)準(zhǔn)庫(kù)擴(kuò)展了語(yǔ)言的定義一樣，現(xiàn)代工具包管理器也大大提高了開發(fā)者對(duì)于體驗(yàn)的預(yù)期。這種擴(kuò)展的優(yōu)勢(shì)在于易上手、開發(fā)體驗(yàn)更好，缺點(diǎn)就是軟件的打包、發(fā)布和構(gòu)建會(huì)帶來相應(yīng)成本。語(yǔ)言作者需要在工具中投入大量時(shí)間來解決這些問題。

我認(rèn)為 cargo 的一大核心優(yōu)勢(shì)，在于它與語(yǔ)言相伴而生。而以往的主動(dòng)構(gòu)建工具往往缺乏與整個(gè)平臺(tái)的全面集成。 

——Robert Masen

工具包管理器正在迅速發(fā)展。所以只要舍得投入工程時(shí)間，我們就能顯著改善自己語(yǔ)言的上手和日常使用體驗(yàn)。于是，新項(xiàng)目在這方面的投入與日俱增。

Rust 的 cargo 和 rustup 文檔在體量上已經(jīng)基本看齊 rust book，而且就這還不足以涵蓋所有 cargo 插件。無(wú)論是輕松切換語(yǔ)言的編譯器版本、快速運(yùn)行測(cè)試、執(zhí)行代碼覆蓋與性能測(cè)試、獲取供應(yīng)商代碼、生成說明文檔、校驗(yàn)代碼還是修復(fù)校驗(yàn)問題，這些以往存在于語(yǔ)言生態(tài)系統(tǒng)中的獨(dú)立工具，如今都成為 Rust 中的開箱即用功能。Go 的情況也差不多?？梢韵胍姡罄m(xù)出現(xiàn)的新語(yǔ)言要想百尺竿頭更進(jìn)一步，需要付出多少努力。

代碼格式化器早在 gofmt 之前就已經(jīng)出現(xiàn)，就如同 CPAN 之前就已經(jīng)出現(xiàn)了第三方工具包，但這一切的最終成熟需要等待一場(chǎng)顛覆社區(qū)標(biāo)準(zhǔn)的深刻變革。

例如，在 Go 之前出現(xiàn)的任何語(yǔ)言，都不可能像 Go 那樣實(shí)現(xiàn)幾乎 100% 的樣式一致性。這是因?yàn)橹暗恼Z(yǔ)言必須兼容原有代碼，而 gofmt 則強(qiáng)制執(zhí)行單一樣式，且不提供任何調(diào)整選項(xiàng)。Go 之后的語(yǔ)言當(dāng)然也就站在巨人的肩膀上，于是 Rust（rustfmt）和 Zig（zig fmt）同樣采用強(qiáng)大的默認(rèn)代碼風(fēng)格與隨附的代碼格式化器，并由此建立起開發(fā)者體驗(yàn)優(yōu)勢(shì)。

其實(shí)可以聊的還有很多，包括運(yùn)行時(shí)改進(jìn)，其基本相當(dāng)于對(duì)語(yǔ)言的直接改進(jìn)。IDE、LSP、模糊支持和重構(gòu)工具等，則把側(cè)重點(diǎn)放在了開發(fā)者這一邊。但受篇幅所限，我們不可能無(wú)限延伸下去。

也有一些在語(yǔ)言創(chuàng)造者眼中必將改變世界的成果，最終從未得到廣泛采用，或者只在某個(gè)特定領(lǐng)域擁有影響力。很明顯，Jupyter notebook 與 REPL 就是典型。它們?cè)谀承?yīng)用領(lǐng)域特別關(guān)鍵，但在其他領(lǐng)域卻毫無(wú)知名度。Smalltalk 基于圖像的方法和 Mathematica/Wolfram 語(yǔ)言的語(yǔ)言集成數(shù)據(jù)雖然極具特色，但也更加小眾。

能幫助開發(fā)者順利完成工作的工具，已經(jīng)是編程語(yǔ)言可用性中的重要組成部分。而工具本身也在持續(xù)變化，標(biāo)準(zhǔn)不斷提高。

整個(gè)過程基本就是：在出現(xiàn)新的開發(fā)者創(chuàng)新工具時(shí)，比較年輕的編程語(yǔ)言更有機(jī)會(huì)將成果融入自身生態(tài)系統(tǒng)，由此形成增量?jī)?yōu)勢(shì)。隨著時(shí)間推移，這些增量?jī)?yōu)勢(shì)會(huì)推動(dòng)開發(fā)者體驗(yàn)迎來質(zhì)變。

于是乎，較新的語(yǔ)言可以用更明確、更精準(zhǔn)的方法解決問題，而舊有語(yǔ)言則面臨大量相互矛盾的方法、甚至完全沒有可行的解決路線。所以，開發(fā)者們才會(huì)普遍認(rèn)為，傳統(tǒng)編程語(yǔ)言工具發(fā)展進(jìn)度緩慢。

原文鏈接：

https://earthly.dev/blog/programming-language-improvements/

• Wasm 的主力，你覺得是誰(shuí)？Go？Rust？
  

我是 polarisxu，北大碩士畢業(yè)，曾在 360 等知名互聯(lián)網(wǎng)公司工作，10多年技術(shù)研發(fā)與架構(gòu)經(jīng)驗(yàn)！2012 年接觸 Go 語(yǔ)言并創(chuàng)建了 Go 語(yǔ)言中文網(wǎng)！著有《Go語(yǔ)言編程之旅》、開源圖書《Go語(yǔ)言標(biāo)準(zhǔn)庫(kù)》等。

堅(jiān)持輸出技術(shù)（包括 Go、Rust 等技術(shù)）、職場(chǎng)心得和創(chuàng)業(yè)感悟！歡迎關(guān)注「polarisxu」一起成長(zhǎng)！也歡迎加我微信好友交流：gopherstudio