解讀程式語言的 2021:Go 與 Rust 走向「成熟」,Kotlin、wasm、Julia「無限生長」
本文是“2021 InfoQ 年度技術盤點與展望”系列文章之一,由 InfoQ 編輯部製作呈現,重點聚焦程式語言領域在 2021 年的重要進展、動態,希望能幫助你準確把握 2021 年程式語言領域的核心發展脈絡,在行業內始終保持足夠的技術敏銳度。
“InfoQ 年度技術盤點與展望”是 InfoQ 全年最重要的內容選題之一,將涵蓋架構、AI、大資料、大前端、雲端計算、資料庫、中介軟體、作業系統、開源、程式語言十大領域,後續將聚合延展成專題、迷你書、直播周、合集頁面,在 InfoQ 媒體矩陣陸續放出,歡迎大家持續關注。
特此感謝
· 阿里雲程式語言與編譯器團隊負責人 李三紅
· Go 語言程式設計專家 郝林
· Julia 社群核心成員 田俊、陳久寧
· 獨立諮詢顧問 /《Rust 程式設計之道》作者 張漢東
· JetBrains 技術專家 / 佈道師 範聖佑
· 英特爾高階技術經理 王鑫
對本文的貢獻。
他們都以直接或間接的形式,參與建設該篇文章,部分內容還以特別策劃的形式獨立成文,出現在盤點合集中。可以說,他們的真知灼見,是該盤點能與大家見面的關鍵。
需要宣告的是,程式語言不能算作一個真正意義上的“技術領域”,因此它在本系列盤點中,顯得尤為特殊。通常,當我們談及一個獨立的技術領域時,往往意味著該技術存在相對獨立的商業價值、產業鏈、開發者群體。但程式語言只是個實現工具,同時又是整個 IT 世界的基礎設施,這種矛盾讓對程式語言的盤點顯得有點沉悶,卻又非常必要。在電影《天國王朝》裡,主角貝里安問薩拉丁,耶路撒冷有什麼意義?薩拉丁回答道:“Nothing”,隨後又說道:“Everything”。同樣的臺詞,套用在“程式語言”身上,或許剛好合適。
另外需要指出的是,IEEE 將程式語言以四個標籤劃分,分別是:用於開發網站和應用的語言(Web)、用於企業、桌面和科學應用的語言(Enterprise)、用於移動裝置端的語言(Mobile)以及用於嵌入式環境的語言(Embedded)。
但在本文中,凡在超過 2-3 個標籤領域都有廣泛應用的程式語言,我們將其稱之為“通用型語言”,以將 C/C++、Java 等語言和 JavaScript、R 等語言做好區分。我們將先對 2021 程式語言巨集觀層面的發展情況做個回顧,再對 Kotlin、Rust、Go、Julia、WebAssembly 五種較有代表性語言的具體發展作垂直解析。
2021 程式語言核心趨勢
通用型語言:關注硬體效能及異構程式設計
近兩年業界出現一種聲音:摩爾定律已經失效了。這主要源於主流硬體廠商在 14nm 工藝上的長時間停滯,以及英偉達 CEO 黃仁勳在 2019 年 CES 展會上的發言:“摩爾定律過去是每 5 年增長 10 倍,每 10 年增長 100 倍。而如今,摩爾定律每年只能增長几個百分點,每 10 年可能只有 2 倍。因此,摩爾定律結束了。”
誠然,這個判斷所引起的爭議是非常大的,無論是蘋果 M1 晶片,還是亞馬遜雲科技的 Graviton3 都在電晶體密度上延續了“摩爾定律”的判斷。但在所有擔憂背後,是 IoT 、AI,乃至元宇宙引發的越來越旺盛的算力需求與硬體工藝極限之間的矛盾。
放在今日,則深刻地影響了通用型程式語言的發展——從早期如何追求單核環境下的極致效能,到今日如何充分利用多核算力。
對協程的支援,就很好地反映了主流程式語言關注點的轉移。2021 最重要的一個動態,當數 2021 年 11 月第三週,Java 即將支援虛擬執行緒(協程)的訊息。訊息來自 Oracle 提交的一份 JDK 增強建議(JEP)草案,草案要求將虛擬執行緒作為 Java 標準版的一部分進行預覽。
草案中提到虛擬執行緒將補充 Java 的平臺執行緒(代表作業系統執行緒),採用輕量級的使用者模式執行緒實現,將更有效地利用可用的硬體,並大大降低成本。虛擬執行緒目的是更好地支援編寫和維護高吞吐量併發應用程式。
這則訊息,意味著最主流的程式語言已經全部支援或正在支援協程,包括 C++、Python、C#、Go(原生) 。這也代表著對硬體效能利用率的關注,已成為各家程式語言的大勢所趨。Python 是其中尤為典型的例子,與 Google TPU 、TensorFlow 生態的高度契合,助其第五次問鼎 TIOBE 年度程式語言。
另外需要重點提及的,是異構程式設計。異構程式設計是對“程式語言 & 硬體效能”這個議題在寬度上的延展。2021 年,華為釋出了北冥多樣性計算融合架構,其中包含了畢晟 C++ 及其他元件,而這裡的畢晟 C++ ,主要是服務於跨 CPU、GPU 算力程式設計的需求。這是國產基礎軟體,在程式語言層面向前邁進的一大步。
如果從這個時間點向前查詢,我們會發現在 2020 年 10 月,英特爾釋出了 oneAPI 1.0,目標在於簡化跨不同計算體系結構的應用程式開發;2008 年,蘋果帶頭建立了跨平臺計算框架 OpenCL;而在更早的十餘年前,英偉達就釋出了 CUDA,用於支援 GPU 程式設計。
問題在於,異構程式設計,無論在語言還是框架層面,學習成本都非常的高。從本質上講,異構程式設計要求開發者對硬體之間的差異性有深刻的洞察,並能結合硬體差異做異常精細的效能調優。這導致團隊引入後,研發效率相對降低(學習成本、遷移成本)。所以常規的通用型語言,也會提供異構程式設計介面作為折中,比如 Java TornadoVM 就是用於支援異構硬體的特性。
況且,異構程式設計底層支援工具的推出和更新,重度依賴於自研硬體的各個廠商。但當今的硬體市場,不但沒有收斂,反而有更加碎片化的趨勢。各家的異構程式設計框架,往往只注重適配自己的體系,對其他的行業主流硬體既不願過問,也沒有足夠的資源過問,這也為底層開發者的工作開展增加了難度。
放眼未來,開源,或許是打破現存問題的一種更好的組織模式。
我們既要效能也要安全,研發效能則需特別討論
這隨之引發了另一矛盾:效能和研發效率,通常是相悖的。在此前 InfoQ 對“Java 之父” James Gosling 的採訪中,他用 Java 和 JavaScript 的區別來說明這個問題。至於記憶體安全,在相當漫長的時間裡,在以 C/C++ 為底層技術棧的開發群體內,則通常不在考慮範圍內。
Rust 在 2021 年的大火,為全行業提供了新的啟發。在 InfoQ 2021 程式語言榜單 中,Rust 無論是關注度還是期望值,都緊隨 Go 語言之後。若單論關注度的增速,Rust 無疑是 2021 年最吸睛的程式語言。尤其是在 2021 年 12 月,Linux 核心和 Rust on Linux 的主要開發者 Miguel Ojeda 向 Linux Kernel 郵件列表提交了一個新補丁 (v2),進一步推進了 Rust for Linux 的工作進展,將公眾對 Rust 的關注推向了新的高潮。
Rust 最重要的優勢在於以媲美 C/C++ 的效能表現,解決了程式設計過程中的記憶體安全問題,從而成為各團隊在系統級程式設計領域的重點調研物件。
C++ 問世四十年,相關方法技巧已經成熟,催生了程式設計大神無數,但在 2021 年的今天,我們仍然在尋找其替代品。其根本原因在於,人們逐漸明瞭,效能並非系統級程式語言的全部,隨著軟體逐漸接管 IoT 裝置(尤其是自動駕駛車輛),記憶體溢位 / 指標懸垂類的記憶體安全問題,已經不只會造成經濟損失,更會威脅人身安全。與其面向結果,出了問題再改 Bug,不如面向過程從一開始就把控好記憶體安全。
但 Rust 的上手難度,又在一定程度上,制約了語言本身的普及(知乎有一吐槽:為什麼用 Rust 實現連結串列都這麼難)。瞭解函數語言程式設計或對學習 Rust 有所幫助,但程式設計世界未來的主流仍將是 OOP(面向物件程式設計)。更大的問題在於中小型公司的替換成本 —— 不存在成熟的人才梯隊,不存在堅實的技術積累,直接採用 Rust 面臨的問題是:無人可招。當下,幾乎所有準備採用 Rust 的公司都是大型公司或創業團隊,前者可以通過內部轉崗積累人才,後者則從一開始就是圍繞 Rust 構建的創業 idea。
相比效能與安全,研發效能在今天反倒成為了一個模糊問題。狹隘地說,選擇一門學習門檻低,開發效率高的語言,就是提升了研發效能;站在更大範圍、更長的時間尺度來看,選擇一門效能滿足研發需求、生態成熟、記憶體安全有保障的語言,也是提升了研發效能;選擇社群夠完善,招聘難度低的語言,方便快速組建研發團隊,也是變相提升了研發效能。
那麼,在 2021 ,一個研發團隊應該如何選擇適合自己的程式語言?在保證了效能需求和安全需求後,則需要結合業務場景、公司發展階段具體分析了。
八仙過海,承諾兌現
除通用型語言外,如果要用四個字形容 2021 年各家垂直領域語言的發展,那麼恐怕是“八仙過海”了。垂直領域用特定語言解決特定問題的趨勢越發明顯,語言的“工具”屬性愈發突出。
在移動端開發,Kotlin 獨樹一幟;在資料科學領域,Python 和 R 語言應用甚廣;在 Web 端,有越來越多的人開始嘗試使用 TypeScript。但需要注意的是,當下所謂的 xx 領域專用語言,或許到了 2022 年,就會產生天翻地覆的變化。如果細細琢磨,你可能會發現,這種變化正在發生,比如 Kotlin、Julia。
WebAssembly 是其中比較另類的存在,它致力於讓其他語言都能以接近原生語言的速度在 Web 端執行,目前最主流的應用是將 C/C++ 編譯為 WebAssembly。其在 2021 的具體進展,我們在接下來的“2021 主要程式語言的具體發展”中單獨討論。
同時,程式語言也在兌現給開發者的無數承諾,那些在社群內早有風聲的前瞻性修改,在 2021 最終完成了“填坑”。
2021 代表性程式語言的發展概況
(關於 Go、Rust、Julia 的更多內容,可額外參考本次盤點特別策劃部分,文章連結詳見附錄)
Go
說到“填坑”,2021 當數 Go 語言最得人心。作為程式語言界最近幾年最受歡迎的一員,Go 卻長期存在三個主要問題為開發者所詬病,即:模組管理工具、泛型語法支援,以及程式錯誤的處理方式。
關於模組管理工具,Go 語言開發團隊基本已經解決或給出路徑;對泛型的支援,相當於有了定論;錯誤處理方式還未找到妥善的解決辦法。而 Go 語言的 2021 主要動態,也是圍繞著模組管理工具和泛型展開。
GO111MODULE 是個系統環境變數,目的是方便開發者們在原始的 GOPATH 機制和新的 go module 機制之間做切換。Go 團隊在 1.16 版本中把 GO111MODULE 的預設值設定為了 on ,這標誌著 go module 機制的成熟。同時,這也說明 Go 團隊已開始正式普及 go module 機制。
從 Go 官方提供的標準工具來看,原有的那些 go 命令都已經完全適配了 go module 機制。比如,go get 命令現在可用於調整 Go 模組的依賴關係,go install 命令現在可用於下載、編譯和安裝 Go 模組, go test 命令現在也可用於編譯並測試 Go 模組,等等。
圍繞模組管理中的配置檔案,另外有三點值得注意:
-
模組圖修剪:在 go.mod 檔案中,針對主模組的直接依賴模組記錄和間接依賴模組記錄已變得完整;
-
新的指令:在 1.16 版本中,Go 團隊為 go.mod 檔案增加了一個新指令。這個指令的名字叫做 retract。我們在這裡可以把它理解為“撤回”,用於撤回當前模組的某個已釋出版本;
-
新的註釋:在 1.17 版本中,Go 團隊為 go.mod 檔案增設了 deprecation 註釋,用來廢棄整個模組。
對泛型的支援,最早要追溯到 2018 年,但直到 2021 年 8 月,Go 團隊才放出了一個終極的設計方案:Type Parameters Proposal( http://github.com/golang/proposal/blob/master/design/43651-type-parameters.md ) 。至此,一個緊密貼合了 Go 語言的泛型模型才算正式出爐。Go 語言的 1.17 版本中已經包含了一些與自定義泛型有關的程式碼,不過要想自由地使用泛型,則要等到 1.19 甚至更遠的版本了。
除此之外,2021 年,Go 在標準命令、標準庫、語法、效能方面都有更新,我們這裡簡單列舉,作為參考:
標準命令:
-
在 1.16 版本,Go 官方對 go install 命令進行了改進,使它可以接受一種版本字尾(如:@v1.0.0),並以此來下載、編譯並安裝(以下統稱為安裝)某個程式碼包的特定版本;
-
從 1.16 版本開始,Go 官方推薦開發者在 go module 機制下只使用 go install 命令來安裝程式碼包,並強烈建議,在使用 go get 命令的時候應該攜帶 -d 標記;
標準庫:
-
新增三個程式碼包:runtime/metrics 包(獲取執行時指標,涉及垃圾回收、記憶體使用、併發排程等)、io/fs(代表了一種全新的檔案系統模型)、embed(在可執行檔案中嵌入額外的資源);
-
廢棄 io/ioutil 包;
語法:
支援從切片到陣列指標的轉換。更具體地說,型別為 []T 的切片現在可以被正確地轉換為以 *[N]T 為型別的陣列指標了;
效能:
-
在 64 位的 Linux 作業系統上,其連結速度比 1.15 版本快了 20%-25%,同時連結操作所佔用的記憶體空間也減少了 5%-15%。此外,由於更激進的符號修剪,Go 程式經處理後產生的二進位制檔案通常也更小了。
-
在 1.17 版本中,Go 團隊實現了一種使用暫存器而不是堆疊來傳遞函式引數值和結果值的新方法。這一新方法讓 Go 程式的執行效能提升了大約 5%。並且,Go 程式產出的二進位制檔案通常也會小 2% 左右。目前,在 Linux、macOS 和 Windows 作業系統的 64 位計算結構上,Go 語言都自動啟用了此功能。
Rust
2021 ,Rust 的熱度絲毫不遜於 Go 語言,但本次盤點特約專家張漢東有一句話說得很好:“Rust 的出現不是為了重寫這個世界已經存在的一切,而是為了讓未來更加美好。”
對於當下本就關注度極高的 Rust 來說,分外適用。
2021 年,Rust crates 的下載總量達到 11,012,362,794 次,即 110 億次。
伴隨著下載量的增長,Rust 語言記憶體安全初步成果也已經顯現。據 2021 年 12 月 31 日釋出於 arXiv 的論文 《SOK: On the Analysis of Web Browser Security》中所言:
比較了四種瀏覽器架構,以及近十年來瀏覽器中記憶體安全問題依然是主流,比如 Firefox 就通過 Oxidation 專案(Rust)替換了 12% 的元件。自 2015 年以來,Firefox 的記憶體安全漏洞數量出現了小幅但穩定的下降,其中,渲染器的記憶體安全漏洞明顯下降。
Oxidation 是專門用於將 Rust 程式碼整合到 Firefox 中的一個專案。Firefox 54 以來,所有平臺都需要 Rust 支援,並且第一個主要的 Rust 元件是在 Firefox 56 (encoding_rs) 和 57 (Stylo) 中釋出的。展望未來,Oxidation 的目標是讓在 Firefox 中使用 Rust 變得更容易和更高效,並相應地增加 Firefox 中的 Rust 程式碼量。
可以說經過六年的應用,Rust 語言的記憶體安全保障終於看到了初步的效果。該論文建議瀏覽器供應商遵循這一最佳實踐,並逐步將他們的瀏覽器轉向記憶體安全的語言。
Rust 語言及相關生態在 2021 年一些看點簡單羅列如下:
-
Rust 編譯器引入了一個新的實驗性 GCC 後端,以及另一個基於 gcc 的實現(目前兩者都在進行中)。
-
Rust 正在進入 Linux 核心,這也為語言和庫帶來了一些改進以促進這一壯舉。
-
Rust 首次進入 Redmonk 指數前 20 名 ,並連續 第六年獲得 Stack Overflow 調查的“最受歡迎的程式語言”桂冠。
-
IEEE 2021 程式語言排行榜,Rust 排 17。按趨勢來排,Rust 在第十位。
-
2021 年初 Rust 基金會剛成立,到年末,已經有二十五家來自不同領域並且有一定建樹的成員。並且基金會也開始落實一些具體安排,比如組織專業的 crates.io 運營。
-
瑞士 Concordium 基金會宣佈 DevX 計劃,將贊助 Rust 生態的維護者們。
-
Espressif (樂鑫)正式僱傭 mabez 針對 eso 晶片開發 Rust 支援:esp-rs。
-
嵌入式 Rust 生態得到長足發展:嵌入式併發框架已經 1.0 、嵌入式非同步框架正在大力開發且支援 STM32,nRF 和 RP2040 平臺,並且還深深影響著 Rust 非同步的改進、嵌入式開發和除錯工具又釋出了新的探針工具、嵌入式 smoltcpTCP/IP 棧釋出了新版本、嵌入式圖形庫 Matrix 釋出了新版本、新的嵌入式實時 OS Hubirs 開源。
-
WebAssembly 領域。前文提到的位元組碼聯盟的 wasmtime 的 Cranelift 編譯後端完成了新的後端架構更改,還得到了 IBM 大型機的支援而引入了新的 s390x 後端。有兩個和 Rust 相關的 Wasm 專案進入了 CNCF :WasmEdge 和 WasmCloud 。
-
圖形計算領域:rust-cuda 和 rust-gpu 這兩個專案,為推動 Rust 成為 GPU 計算第一語言開始發力。前者是將 Rust 作為 GPU 第一語言,後者則推動 Rust 成為圖形渲染第一現代化著色語言。
-
國內 Rust 職位招聘有所增長:位元組跳動、海致星圖(圖資料庫)、非凸科技(量化)、達坦科技(分散式儲存)、Datebend(資料倉儲)都大量需要 Rust 人才。
-
GUI 領域的 SixtyFPS 和 tQCS 這樣的諮詢公司建立了合作關係,找到了第一個客戶,招募了新成員。tQCS 提供世界 No.1 的 Qt 諮詢和 UI/UX 設計服務,選擇和 SixtyFPS 合作,這也算是 Rust 在 GUI 領域的一個里程碑。
-
Embark Studios 釋出了它們公司第一個 3A 遊戲,在其遊戲後端也用到了 Rust 。Embark Studios 是 Rust 遊戲工作組的成員之一,致力於將 Rust 推廣到遊戲開發中。rust-gpu 庫就是他們開源的專案之一,並且該公司也贊助了很多遊戲和圖形學相關的 Rust 生態庫。
-
Rust 在 音影片領域也得到了應用,Signal 公司使用 Rust 開發了支援 40 人高質量語音群組通話的服務。
-
Rust 也成為前端基礎設施的一員:Next.js 公司用 swc 和 Rust 完全取代 Babel(transpilation)和 Terser(壓縮)。
就版本更新而言,Rust Edition 現在已經確定了 —— 每三年釋出一個版次。這就意味著 Rust 每三年都會圍繞一個引領 Rust 發展的主題。
2021 Edition 的主題是「成熟(Mature)」。2021 edition 並沒有引入太多新特性,而是清理了一些技術債務,比如持續對 Rust 編譯器進行重構和改進,包括內部使用的新的 trait 系統 chalk 和 query 系統(開源版本: http://github.com/nikomatsakis/salsa )。另外還處理了一些向後相容的問題,以及持續投入一些影響未來發展的關鍵特性,比如 常量泛型、泛型關聯型別等。
前文我們也提到, Rust 今年的一個重要動態就是對 Linux 核心的支援。到 2022 年,我們很可能會看到 Linux 核心中的實驗性 Rust 程式語言支援成為主流。而在 2021 年 12 月 6 日早,Rust 團隊發出的更新的補丁中,則介紹了在核心中處理 Rust 的初始支援和基礎設施。
這次更新的內容包括:
-
升級到了最新 Stable 編譯器和 Rust 2021 edition 。因此可以擺脫了 const_fn_transmute,const_panic、const_unreachable_unchecked、core_panic 和 try_reserve 這幾個之前未穩定的特性。
-
自定義 core 和 alloc。為 alloc 添加了更加模組化的選項,以便禁用一些他們不需要的功能:no_rc 和 no_sync,主要是為上游 Rust 專案新增。
-
更嚴格的程式碼、文件和新的 lint。
-
抽象和驅動程式更新。添加了序列鎖、電源管理回撥的抽象,io 記憶體(readX/writeX)、irq 晶片和高階流處理程式,gpio 晶片(包括 irq 晶片)、裝置、amba 裝置和驅動程式以及證書。此外,也改進並簡化了 Ref(refcount_t 支援)物件並用它替換了 Rust 的 Arc 的所有例項。完全地從 alloc crate 中刪除了 Arc 和 Rc。
從現在開始,Rust for linux 團隊將開始定期提交補丁,每兩週左右。
關於 Rust,還有一點不得不提,那就是發生在年末的稽核團隊(mod team)集體離職事件。但當塵埃落定,事件本身的性質已經不好評價,涉及美國獨有的政治、文化及種族問題。張漢東在採訪中說道:
“2020 年 Rust 1.44 版本釋出時,官方部落格說過這麼一句話:「tech is and always will be political」。對於美國文化不太瞭解的我,之前還對稽核團隊存在的重要性嗤之以鼻,現在感覺稽核團隊的存在對於 Rust 這樣深處文化政治複雜的美國是多麼重要。我終於理解 Rust 官方團隊所說這件事的背景相當複雜的原因了。真心希望 Rust 團隊能處理好這件事。對此,我們能做些什麼呢?也許只能祈禱世界和平。”
Kotlin
2021 年剛好是 Kotlin 10 週年,在這一年裡,Kotlin 共釋出了 1.5 及 1.6 兩個版本,目前最新版本為 Kotlin 1.6.10。如果要將其中的關鍵動態總結一下,那麼會分為如下四點:
-
K2 編譯器:目標是全新打造的編譯器架構,提供更好的效能併為多平臺發展建立良好的基礎。
-
Kotlin Multiplatform Mobile(KMM)持續更新,預計在 2022 年春天發表 Beta 版本;
-
Kotlin/JS:新的 IR 編譯器發表 Beta,更多 JS 庫遷移到新 IR 編譯器;
-
Compose Multiplatform 1.0:可用於 Desktop 和 Web 的宣告式 UI 框架,對安卓開發者來說,更容易從 Jetpack Compose 切入;
K2 編譯器是 Kotlin 在 2021 年最重要的更新。編譯器分為前端和後端,功能包含生成語義資訊的 IR (中間表示),並轉為相應目標平臺(JVM、JS、Native)的可執行檔案。Kotlin 1.5 版本就已經開始支援 K2 編譯器,目前 Kotlin/JVM 已是穩定版本,Kotlin/JS 是 Beta 版本。
Kotlin 的開發生態圈非常活躍,目前 Kotlin 團隊共有約 100 位開發人員,超過 360 位開源貢獻者參與開發工具,2021 年約有 25 萬個與 Kotlin 有關的程式碼倉庫在 GitHub 上被創建出來。
有兩份報告可供我們參考:
開發人員及開源貢獻者資料:
http://kotlinlang.org/lp/10yearsofkotlin/present/
Kotlin 開發生態系調查:
http://www.jetbrains.com/zh-cn/lp/devecosystem-2021/kotlin/
而 2021 年, Kotlin 整個生態的活躍,也從側面印證了這些官方團隊和開源貢獻者的工作成果。生態進展如下:
JetBrains 方面:
-
UI 框架:Compose Multiplatform 1.0
-
Server-side:Ktor 2.0 beta,Kotless 0.2.0
-
Data Science 及 ML:Kotlin API for Spark,Kotlin DataFrame library,KotlinDL
-
工具:Dokka 1.6(文件引擎),Kover(程式碼覆蓋率),Qodana(靜態分析器)
社群方面:
-
Spring Native
-
Arrow (Kotlin library for functional programming) release 1.0
-
Koin (dependency injection framework) release 3.0
-
KorGE (Game engine) release 2.0
-
Okio (I/O library for Kotlin Multiplatform) release 3.0
-
Apollo (GraphQL client) release 3.0
此外,Kotlin 也很重視中國開發者的生態建設,2021 年,他們與 Kotlin User Group 合作,舉辦了中文開發者大會,吸引了 1500+ 觀眾參加。
Kotlin 2022 年的發展重點可以總結為如下四點:
-
持續發展 K2 編譯器:優化效能、編譯速度及支援外掛的能力
-
改善開發者體驗:優化 Kotlin IDE 外掛,提升穩定度及效能,讓修改、測試除錯迴圈可以更高效
-
深化支援 Kotlin 在 Server-side 的應用:更多是 Spring 及 Ktor 方面的應用
-
推出新版 Kotlin Multiplatform Mobile(KMM):預計在 2022 年春天推出 Kotlin Multiplatform Mobile Beta,並持續改善共享程式碼的開發體驗
(具體路線圖可參考: http://kotlinlang.org/docs/roadmap.html )
而在這背後,是 Kotlin 積極地向多平臺語言演進的努力,用本文的話語體系來講,就是“通用型語言”。我們可以看到 JetBrains 提供了多個支援多平臺的庫如 kotlinx.coroutines,kotlinx.serialization,kotlinx-datetime,而 Kotlin 社群也緊跟著這樣的趨勢發展,出現了愈來愈多的庫、框架來支援多平臺,如 Arrow、Okio、Apollo 等在新版本中都支援了多平臺開發。
令 Kotlin 社群工作者苦惱的是,自 2017 Google 發表宣告後,Kotlin 總被當成是 安卓專用開發語言 。實際上,Kotlin 極有可能在接下來的兩個領域成為主流程式語言:
-
Desktop:設計 Kotlin 的初衷就是要拿來開發 IntelliJ IDEA,隨著 Compose Multiplatform 的釋出,使用 Kotlin 開發 Desktop 軟體將更加輕鬆;
-
Server-side:Kotlin 100% 與 Java 互操作的特性讓許多 Java Server-side 開發者轉而使用 Kotlin,現也有 Spring 官方的支援及 JetBrains 推出的 Ktor 框架,使用 Kotlin 開發 Server-side 應用將有機會成為主流。2021 年 使用 Kotlin 做 Server-side 開發的使用者提升了 40%,可見其潛力;
同時,Kotlin 對 WebAssembly 的支援工作也提上了議程,未來也將成為 Web 端程式語言的可選項之一。
就這一點而言,我們倒不妨大膽暢想 Kotlin 2022 年的發展態勢,看其在未來幾年內,能否重現當初 Objective-C 兩奪年度最佳程式語言的盛況。
Julia
在剛剛過去的 2021 年,Julia 程式語言社群依然保持了高速發展。據統計,目前 Julia 的全球總使用者量已超過一百萬,有一萬多家公司和一千五百多所高校下載和使用了 Julia。此外,一些世界名校,如北京大學,MIT、Stanford 和 Berkeley 等,已經在教學中使用 Julia 語言。Julia 預設的登錄檔中新增了 1128 個包,累計達到了 5397 個。詳細的資訊可以前往 JuliaHub.com 檢視,獲取各個庫下載資訊的方法也已在官方論壇中公佈。
2021 年,Julia 釋出了兩個重要版本,分別是 [email protected] 和 [email protected]。此外,在 [email protected] 於 11 月 30 日釋出的同時,社群正式宣佈 [email protected] 為新的長期支援版(LTS)。Julia 官方部落格中詳細介紹了 [email protected] 的一些新特性,這裡我們列出尤其值得關注的幾點:
-
全新的多執行緒特性:解決了許多執行時的競態條件,優化了多執行緒之間任務的排程,同時讓預設的隨機數生成器對多執行緒更加友好,此外還新增了一類原子操作作為基本的語言特性;
-
包管理的更新:新版的包管理工具會自動識別出該包是否已經註冊,如果是的話,則會提示你是否要自動安裝;
-
對 Apple Silicon 的支援:[email protected] 是首個能執行在 Apple Silicon 上的版本,但對該平臺的支援還僅處於 tier 3 (即僅處於實驗性質,編譯 / 測試有可能失敗);
-
BLAS/LAPACK:執行時的後端切換;
-
編譯延遲和執行時體積優化;
-
更好的型別推斷、程式碼分析和檢查;
而在社群和生態方面,Julia 的進展和動態極多。關於社群,我們尚可簡述重點:FluxML 社群於 12 月 1 日正式宣佈掛靠在 NumFocus;JuliaComputing 完成 A 輪融資。
以及國內映象站進一步增加,包括:
-
北京外國語大學 (http://mirrors.bfsu.edu.cn/julia)
-
清華大學 (http://mirrors.tuna.tsinghua.edu.cn/julia)
-
上海交通大學(http://mirrors.sjtug.sjtu.edu.cn/julia)
-
中國科學技術大學 (http://mirrors.ustc.edu.cn/julia)
-
南方科技大學 (http://mirrors.sustech.edu.cn/julia)
-
南京大學 (http://mirrors.nju.edu.cn/julia)
但關於生態,以及 Julia 在行業內的實踐,則受限於篇幅,需要你移步附錄中的特別策劃了。總的來說,Julia 的發展和 Kotlin 有共通之處,都在由特定領域的專用語言,轉而向多領域通用語言發展。
WebAssembly
於 WebAssembly 而言,2021 年發生了一件大事。
就在 2021 年的 10 月, Photoshop 釋出了 Web 版本,大量使用了 WebAssembly。Photoshop 是傳統的巨型桌面軟體,程式碼庫完全基於 C++ 編寫。這次成功釋出 Web 版本,驗證了大型、高複雜度、基於傳統高階語言編寫的軟體,是完全可以通過 WebAssembly 執行在 Web 端的。
而在區塊鏈智慧合約領域,WebAssembly 因為對 Web 的相容,且允許使用 C++、Rust 編寫高效能程式,已成為事實上的王牌語言。在 IoT、可信計算、輕量級容器等領域內,WebAssembly 都有十分契合的特性。這讓開發者群體對 WebAssembly 的關注度迅速增長。
2021 年,WebAssembly 語言技術值得關注的發展包括:
-
WebAssembly 開源專案開始支援 GC(垃圾回收器),為實現 WebAssembly 支援像 Java、Kotlin 這樣的前端語言做準備;
-
WebAssembly SMID 可變長度取得關鍵進展,幫助 WebAssembly 應用充分獲得 CPU 向量化計算加速能力;
-
WebAssembly 模組化取得關鍵進展,為進一步構建 WebAssembly 的生態提供了核心的支撐;
-
原始碼除錯能力的增強,WebAssembly Micro Runtime 和 WASMTIME 等開源專案都提供了原始碼的除錯能力,極大促進應用開發的效率
另一個重要動態是“位元組碼聯盟(Bytecode Alliance)”正式成為了非營利性實體組織,致力於開發基於 WebAssembly 和 WASI 的安全開源軟體棧,建立一個預設安全的 WebAssembly 生態系統,讓應用程式開發人員和服務提供商能夠自信地在任何基礎設施、任何作業系統或裝置上執行不受信任的程式碼。位元組碼聯盟發展十分迅速,其成員包括 Fastly、英特爾、微軟、Google、Amzaon、Arm、 西門子等企業。業界普遍期望位元組碼聯盟可能會更有效率地推進 WebAssembly 的更新和迭代工作。
更多的程式語言,如 Python、Swift……我們難以在同一篇文章中全部盤點,只能寄希望於 2022 年,我們繼續關注程式語言領域的核心動態。相信在 2022 ,各大程式語言也會為開發者帶來新的驚喜。
附錄:2021 程式語言盤點特別策劃及 Java 2021 部分動態盤點
解讀 Julia 的 2021:逐步邁向主流程式語言: http://url.cy/Sr7oU1
解讀 Go 語言的 2021:穩定為王: http://mp.weixin.qq.com/s/9LKyPfhwldgZY7H4iS7sjg
解讀 Rust 的 2021 (上): http://mp.weixin.qq.com/s/aTCogUxyUwE6Sa4Nfs9CYA
Java 2021 部分動態盤點: http://www.infoq.cn/theme/125
如果你對本文感興趣,歡迎在文末留言,或加入 InfoQ 寫作平臺話題討論:
(http://xie.infoq.cn/article/2b890228e7b642b4026a5a261)
後續,迷你書、專題將集合釋出與 InfoQ 官網,登入 InfoQ 官網:
http://www.infoq.cn/
註冊並將 InfoQ 新增進收藏夾,精彩不錯過。
同時,2021 InfoQ 年度技術展望直播周已於 2021 年 12 月 22 日首播,後續回放影片和文章也會在 InfoQ 官網放出。
- 2022,百度飛槳迎來這「6 大升級」
- 建設桌面作業系統根社群,統信軟體深度社群有哪些硬思考?
- 什麼是可程式設計代理,為什麼我們需要它
- JDK11 的 11 個謎題:Hanno Embregts 在 Devoxx UK 闡述對 Java 認證的理解
- 如何看待 Dapr、Layotto 這種多執行時架構?
- 軟體開發的核心原則
- 檢視 Docker 容器的資訊
- “史上最嚴”資料保護法GDPR是如何失敗的?
- Web3 系統構建:去中心化的原則、模型和方法(上)
- 失敗的數字化轉型浪費了 412 萬美元,架構師們壓力山大
- Web 3.0 只是高成本版的 P2P 而已
- 我們用了一個週末,將 370 萬行程式碼遷移到了 TypeScript
- 初創資料庫公司的瘋狂行為:刪掉花 7 個月開發的 27 萬行 C 程式碼,用 Rust 全部重寫一遍
- 現代程式語言需要泛型
- 首席資料官是怎麼煉成的?
- 混合雲的多活架構指南
- 為什麼校招面試中“執行緒與程序的區別”老是被問到? 我該如何回答?
- 跨平臺應用開發進階 (八) :uni-app 實現 Android 原生 APP- 雲打包整合極光推送 (JG-JPUSH) 詳細教程
- SpringMVC 原始碼分析:POST 請求中的檔案處理
- 如何在 Web 應用裡消費 SAP Leonardo 的機器學習 API