微軟首席工程師:Rust 將面臨十大挑戰

語言: CN / TW / HK

微軟首席工程師 Nick Cameron 釋出了一篇部落格,指出了他認為現在和未來幾年 Rust 將面臨的十大挑戰,並提出了一些初步的解決方案想法。目前,Nick Cameron 主要負責該公司 Rust 相關的工作;曾經,他還是 Rust 核心團隊的成員。

Nick 指出,現如今 Rust 正處於一個良好的發展局面;受歡迎程度越來越高、貢獻者越來越多,還在一些重要領域進行了應用。但在這個充滿變化的時代,從一個研究專案到一個新的、快速變化的語言再過渡到一個流行的、成熟的專案,是一個困難的演變過程。

“在這裡,我想描述一下我認為現在和未來幾年 Rust 面臨的十大挑戰。我有一些解決方案的想法,但它們都是大而難的問題,沒有簡單的答案,所以真正的解決方案都需要迭代、精力和創造力。我的重點是核心專案;社群和生態系統面臨許多挑戰(例如,如何使用 Rust 製作 GUI,或者如何讓更多的 crates 進入 1.0),我認為這些挑戰必須主要由社群來解決。”

具體內容如下:

治理挑戰

1、如何引導開發並保持 Rust 的開放性?

開源工作中,在什麼是對專案最有利的,以及什麼是志願貢獻者想做的之間總存在著一些矛盾。現在,隨著 Rust 社群逐漸發展壯大且 Mozilla 結束直接支援,Rust 中的這種緊張關係似乎也在日益加重。儘管有很多人從事基本的維護工作,但往往人手不足;一些重要領域也缺乏資源、缺乏引導貢獻的戰略工作或努力。

Nick 認為, 在某些方面,採用自上而下的方法可能會更容易;但此舉也或將導致 Rust 失去作為開源專案所擁有的一些優勢。最大的挑戰是確保在完成重要但不吸引人的工作的同時,同時又不失去專案中使其令人敬畏的部分特性。 Nick 表示,他們 目前正在努力解決一些具體問題,包括:

  • 優先完成眼前的工作而不是開始新工作,
  • 優先考慮工具、庫和非技術工作以及語言和編譯器,
  • 優先考慮影響較小、成本較低的工作,這些工作總體上可能會產生很大的影響(超過大型、迷人的工作)。

與這一挑戰相關的是在面對增長時保持 Rust 的基本特徵。特別是,專案如何發展並接受新的貢獻者和領導者(以及隨之而來的不可避免的變化)而不忽視 Rust 的核心使命?隨著觀察者(和評論者)數量的增加,我們如何在討論和決策中繼續保持公開和透明?

2、多樣性和包容性

Rust 的多樣性狀況很糟糕。儘管在成為一個包容性專案方面 Rust 做的可能還不錯,但還是有諸多貢獻者因為某些消極原因而不得不離開了該專案;避免倦怠也是包容性的一部分。

包容性的一個重要方面是能夠容納各種意見。如果我們只有在每個人都同意的情況下才能相處,那麼我們就不可能多元化或包容。雖然我們對共識的偏好在某些領域對我們很有幫助,但它也帶來了問題。我們避免衝突而不是解決衝突的文化是不健康的,並導致治理功能失調。 這些真的很難解決!但我們必須優先解決它們,即使它們很困難,有時也很痛苦。

3、避免低效流程的僵化

Nick 稱, 過去的幾年裡在 Rust 飛速發展的同時,其流程和組織卻並沒有跟上步伐。在任何與治理或流程有關的事情上,都存在著巨大的變革慣性。即使現有的流程有大量的摩擦,但除了在此之上進行調整之外似乎也無可奈何。“我們已經積累了如此多的組織債務,以至於需要進行徹底的變革,但進行這種變革將是非常困難的。”

他認為,問題的核心是專案不願意接受“管理”(人員管理、專案管理、產品管理)作為專案領導的重要組成部分。這些事情可以獨立於技術領導,但需要真正的權力委派(不僅僅是工作委派)。該專案面臨的挑戰是接受委託,支援這些活動,並引入更好地支援該專案的新流程。

生態系統挑戰

4、Navigating the crate ecosystem

Rust 在最小標準庫和“batteries included”之間取得了很好的平衡,原因在於其有一個繁榮的生態系統和易於使用的軟體包管理器。然而,有關 crate 生態系統一直是個棘手的問題。存在很多 crates,要找到適合的則需要付出很多努力,或者說要很好地參與到社群中去。隨著越來越多不是社群積極參與者使用者的出現,以及 crate 數量的增加,這將成為一個更大的問題。

5、The async ecosystem

非同步程式設計對於 Rust 目標的許多領域都很重要,且與 Rust 的程式設計模型配合得很好。然而,其生態系統在不同的執行時有些分裂;雖然有在進行相關的改進工作,但卻進展緩慢,最終成功與否也未能確定。“風險在於我們最終會將東西帶入標準庫,這些東西並沒有得到社群的廣泛接受,我們最終會得到一個比我們開始時更糟糕的生態系統。”

技術挑戰

6、如何在不失去其 core focus 的情況下使語言更具廣泛吸引力?

Nick 認為 Rust 在其現有成功基礎上仍有很大的增長空間。目前的很多軟體都是用更側重效能的語言編寫,Rust 對安全、人體工程學和效能的關注則可以製造更好的產品並提高生產力。然而相對而言 Rust 學習難度和成本都太高,讓 Rust 更容易學習和使用可能會擴大其影響力。

我不認為支援 GC、對 型別使用含糖語法或新增一堆語法糖是解決方案。我們必須在不失去 Rust 以系統程式設計為核心的優勢的情況下讓事情變得更簡單。減少對 explicit lifetimes 的需求,使 borrow checker 更強大,不要使 trait system 過於複雜,關注使用者體驗,避免成為一種臃腫的語言,這些都會有所幫助。也許我們會發現可以顯著簡化所有權和生命週期的新 abstractions?

7、記憶體模型和不安全程式碼

安全性是 Rust 主要特色之一,也是許多人使用它的動力。因此需要能夠為從事不安全工作的程式設計師提供更多支援和更好的體驗。要做到這一點,則需要對 Rust 的記憶體模型有更清楚的瞭解,然後開發語言特性、庫和工具。

幸運的是,這個領域有學術研究、出色的社群工作、MIRI、不安全程式碼指南等等。不幸的是,這是一個非常複雜和困難的領域,許多外圍人士的意見會減慢進度,並增加相關人員的工作難度。 Nick 指出, 出於政治和技術原因,一些可能真正影響大的更改根本無法進行。

8、發展標準庫

標準庫除了單調增長之外沒有其他方法可以發展(可以棄用但永遠不會刪除,並且無法更改)。就其本身而言,這將導致標準庫變得越來越龐大和混亂。但也有二階效應:必須對穩定性採取極其保守的態度,除了“stable forever”和“僅在 nightly 可用且完全可能發生變化”之外,API 沒有其他可能的狀態。

相關地,標準庫是一個 all or nothing deal(技術上也有 liballoc)。除了有一個更細化的版本管理解決方案外,更細化地使用標準庫,而不僅僅是核心庫或所有的標準庫,也是有益的。

9、Big compiler changes

Rustc 現在是一個非常龐大的軟體。它有很多固有的複雜性(Rust 是一種複雜的語言,在快速編譯的同時提供良好的錯誤資訊是非常困難的),很多大型軟體的常見問題以及大量的技術債務。存在一些重大挑戰,尤其是在編譯時間方面(其中增量編譯和並行編譯是兩種正在進行中的方法),而這些都被證明是難以實現的工作;未來想要做出重大改變只會變得更加困難。幸運的是,編譯器團隊有能力、精力充沛且資源充足。但是,要對 rustc 進行大的、高影響的更改仍然具有挑戰性。

10、Macros

Macros 是語言中最不完善的部分之一。Declarative macros 引入了一種全新的子語言;Procedural macros 則很笨重,需要大量依賴並且難以掌握。所有的巨集都與編譯器(編譯時間、增量編譯、錯誤資訊)和工具(IDEs、rustdoc等的各種問題)配合得很差。

我認為這是一個巨大的挑戰(而不僅僅是另一個可以處理的語言特性)的原因是,這些問題是分散的和困難的。(可能)沒有良好的解決方案,只有大量的工程和設計工作。許多問題(例如,macro hygiene)需要社群中不存在的專業知識。巨集的優先順序也不夠高(畢竟它們本質上是有效的),也沒有足夠的魅力來吸引貢獻者。

展望

Nick 最後總結稱,他列出了十個所謂“大”的 Rust 問題, 可能會讓人感覺有點消極;但這確實都是現實中所面臨的挑戰。幸運的是,專案內部的人都知曉這些問題的存在,並在積極地解決中。

儘管任何解決方案都很困難,但我認為所有這些挑戰都有可行且現實的解決方案。如果我們能夠專注於解決這些問題(當然還有其他所有的日常挑戰),那麼我認為 Rust 將繼續發展並取得成功。

詳情可檢視部落格全文。