作者 | STEVE KLABNIK
譯者 | Arvin，責編 | 夕顏
頭圖 | CSDN 下載自視覺中國
出品 | CSDN（ID：CSDNnews）
最近我一直在思考Rust的變更頻率。有些人斷言，Rust如今保持著較少的變動，趨於平靜，還有一些人說Rust的變化仍然太大。在這篇博文中，我想通過數據，分析一下這個問題。首先我會提出我的看法，接下來介紹我的方法論，然後分析結果，最後討論可能的方法論問題以及進一步研究的可能方向。
如推特上所說：我已經完成了調研，看到事實結果，並分析了晦澀的數據，我的結論是針對rust的發展變化，大多數人比我更氣憤。
我的看法
我對Rust變化的個人看法：對我來說，Rust過去的變化比現在多。變動也越來越小。這就是我的看法。
方法論
我們可以用多種不同的方法來衡量“ Rust多久變更一次？”這一問題。因此，在開始收集數據之前，我必須確定一些細節。
我意識到我前提是人們對Rust的感覺。那麼，他們對於Rust的變化是如何理解的？我們將變更信息傳達給Rust社區的主要方式是通過發佈博客文章。所以我決定從博客文章開始。
我在一個新選項卡中打開了Rust的每一篇博文，從1.0.0到1.42.0。為了好玩，我還打開了1.43的發行說明，這個版本很快就會發布。
然後，我查看了宣佈的每個更改，並將它們歸類如下：
添加語法
語言
標準庫
工具鏈
重大變化（major）
中等變化（medium）
稍小變化（minor）
我最初也將“已廢棄（deprecation）”和“穩健的（soundness）”作為分類，但最後我沒有把這些包含進來。稍後再詳細介紹。
從這裡開始，我必須決定這些類別的含義。我在這裡應該使用什麼標準？下面是一些簡單的例子:
語言更改意味著對語言定義的某種修改。所幸我們的policy比較穩定，這些只是附加的更改，但也屬於新的補充。
標準庫更改意味著對標準庫的變動，主要是新功能、新類型、新方法等。這是一個非常簡單的標準，但是稍後會涉及一些有趣的方法論小問題。
與cargo、rustup、新編譯器目標支持等相關的工具鏈更改。不是語言本身的一部分，而是Rust發行版和Rust程序員將使用的東西的一部分。
現在，是那些難度較大的變更:
重大變化/中等變化/稍小變化三類劃分原則是認為該變動程度有多大。這裡有幾個有趣的部分。首先，這當然是非常主觀的。從今天起，我決定嘗試對它們進行評估，也就是說，有些變化可能被我們認為是重大變化，但今天在實踐中並沒有經常使用，因此我將這些變化歸類為中等的而不是重大的。與嘗試記住當時的感受相比，這對我而言更加一致。
添加語法的更改聽起來很容易，但實際上非常棘手。例如，考慮“ 模式中的點 （
https://github.com/rust-lang/rfcs/blob/master/text/1492-dotdot-in-patterns.md）”這樣的功能。這確實會改變語法，例如，你可以說它增加了語法，但是，作為一名程序員，我並不真正在乎語法。此功能的摘要是“在更多上下文中允許..模式片段”。變更說明還說到：
該RFC旨在“完善”該功能，並使其在所有可能的列表上下文中都能工作，從而使該語言更加方便和一致。
我認為這些更改實際上是這個想法的核心，因此我決定根據自己的看法對它們進行分類：這不是新的語法更改。想必您現在已經被迫地瞭解了..。
我相信這可能是我分析中最具爭議的部分。當然，稍後會詳細介紹。
好的，這就是我介紹的內容。但是還有一些我沒有講的東西。我做了足夠的工作，但仍忽略了這些東西：
編譯器加速。分析這些數據很有趣，但這實際上意味著編譯內容，而我沒有時間做這個。這本身是一個獨立的研究。
文檔工作。這往往不會算作新功能，但有時會在發行說明中出現，以進行更大的改進。最好保留它。我也不認為這完全影響我的假設。
部署新特徵的庫類型。這些可能很難被統計，尤其是涉及泛型時。我決定最好不要算這些。
編譯器內部消息。我們有時會談論像“MIR現在就存在!”或者“我們將構建系統從make移植到cargo!”“但與文檔類似，我們很少談論這個話題。這也不是一個影響最終用戶的變化，或者更確切地說，它是通過被統計的內容更直接地影響最終用戶。MIR啟用了NLL, NLL被算作一種語言功能。
結果和分析
我不像我想的那樣擅長谷歌表格，所以我請求幫助。非常感謝Manish幫我把這些整理好。他幫了我很大的忙，但是後來我又調整了很多東西，所以出了錯算我的。例如，我有點懶，沒有意識到各種圖表的顏色都不相同。我的錯。
這是我發現的變化和每種變化的簡要彙總：
以下是每個發佈版本的一些圖表：
首先，很顯然，至少從數據上來說，標準庫是Rust最經常更改的部分。從數量上看，這是一個明顯的異常值。我發現這種結果有點滑稽，因為Rust以擁有小型標準庫而聞名。我們將在下面的“問題和進一步研究”部分中進一步討論我為什麼這樣認為。
讓我們看一下沒有標準庫的圖表：
你可以看到在早期有大量的工具鏈改變。我們在早期有很多工作要做，所以做了大量的改變!它在最近幾次趨於平靜，但是工具鏈的變化幾乎是語言變化的兩倍。我還注意到，工具鏈變化的減少可能是由於方法論的原因。我會在後面的文章中討論這一點。
所以，這裡的核心問題是:最近語言的變化似乎更多了，而不是更少了。我認為很明顯，這張圖並不是我想象的那樣，也就是說，在我的設想中應該有一條平緩的下降曲線，但事實並非如此。我想再深入一點，但首先，讓我們看看其他一些圖表:
添加語法的更改也算是語言變更。總體而言，添加語法並不多。Rust 2018很特殊。我們發佈的版本中有一半沒有添加語法，儘管43個版本中有10個引入了語言變化。我們的前29個版本跳過了1.26，平均大約有一到兩個變化，但此後每隔一段時間，就會有三到四個變化。我相信這與我的方法論有關，但同時，這也有力地反駁了我的假設。非常有趣!
這是重大/中等/次要變化的統計圖：
Rust 2018出現了一個高峰，從1.12到1.19出現了一個高峰，但除此之外，就整體變化而言，最近一直相當穩定。如果我們只看重大變更：
Rust 2018發生了巨大的變化。在1.0之後，以及Rust 2018之後，它平靜了下來。我認為這張圖表非常有趣，並且很好地展示了3年版的週期。我們發行一個版本，恢復平靜，步入正軌，循環往復。
那麼，為什麼我的假設是錯誤的？我認為這個結論很有趣。我認為部分原因與我的方法有關，也許，這種差異解釋了人們對Rust的一些看法。你看，即使我們非常頻繁地發佈，而且很多發佈並沒有太多的變化(正如你所看到的，除了標準時，平均大約是8或10個變化)，事實上，我們確實會經常發佈並且會有相當不錯的變更，但數量很少，這意味著發行說明中會包含一些內容，如果我們進行的變更數量完全相同，則可能不會發布，而是每年發佈一次。
例如，在2019年，我們將Rust 1.32發佈到1.40，涉及35個語言更改。如果我寫一篇關於這一整年所有這些變化的文章，我會寫“你現在可以在enums上使用#[repr(align(N))]了”嗎?可能不會。但是由於該版本中總共只有八處更改，其中一半是語言更改，因此將其包含在1.37版本中是有意義的。
這是否意味著那些閱讀發行文章並認為Rust發生了很大變化的人是錯誤的？不，不是的。對於我們這些身處其中的人來說，很多細微的變化在背景中顯得有些模糊。實際上，我在寫上面這句話的時候，一開始是在enums上鍵入了“#[repr(N)]”，因為這個更改與我或我的工作無關，而且非常小，使事情更加正交，所以對我來說，它只是一種模糊的背景噪音。但是對於那些不太熟悉語言的人來說，很難知道什麼是大的，什麼是小的。無窮無盡的發佈帖子中包含了大量的內容，讓人感覺發生了很多事情。但是同樣的事情也可能發生在其他語言中，你只是在發佈文章中看不到它們，因為它們一年只發布一次。你會更少地看到他們，也更少地看到他們包含的內容。
我不認為這意味著Rust項目應該更改其發佈時間表，並且我不確定是否應該更改我們編寫發佈帖子的方式。但是，也許有一種更好的方法來顯示“這些是大的改變”與“這是一件小事”或類似的東西。我不確定。但是我確實認為這可以幫助我更好地理解這種脫節。
問題和進一步的研究
這種方法存在一些大問題。沒有任何分析是完美的，但我想盡可能客觀，因此至少我要把所有我能想到的東西都說出來。
首先，這件事本質上是主觀的。有不同程度的主觀性。例如，“註釋中的全部更改”是相當客觀的，但並不完全。人們必須自行決定發行說明中的內容。因此，在我開始看數據之前，已經進行了一次過濾。做這個分析花了我兩天的時間，但實際工作只花了幾個小時。以自動化方式分析git repo的內容可能會看到其他結果。我認為這種主觀性還可以，因為畢竟我們的測試也有一定主觀性。而且我認為我設計的方法學考慮到了這一點。在某種程度上，“真實的”答案是否Rust變動很小並不重要：人們仍然可以通過閱讀帖子來獲得此信息，因此我不認為這是“哦，是的,你有這樣的感覺,但這張圖表示你的感覺是錯誤的”真的會幫助這場辯論。
第二個問題在此討論。我們大概有三個代際的發行說明：前幾篇文章是由Aaron和Niko撰寫的。從Rust 1.4開始，我接手了這項工作，直到1.33之前，幾乎每一篇文章都是我寫的。然後我退出了一段時間，儘管我確實幫助撰寫了1.42版本的帖子。發佈團隊繼續編寫了1.34，與以前的帖子相比，這一版本更多的是協作。這意味著從發行說明->博客帖子中進行過濾的人會隨著時間的推移而改變。這可能會打亂統計。例如，有些博客文章可能會省略一小部分功能，但是撰寫該文章的人將它們全部單獨包含在內。這可以解釋最近語言變化的加劇，以及為什麼其中許多沒有被評為“重大變化”的原因。此外，從“ PR列表”到“發行說明” 進行過濾的人員也隨時間而變化，因此那裡的過濾也有所變化。
更復雜的是，從Rust1.34開始，發行博客文章中Cargo不見了。雖然Cargo發生重大變化時還是會出現在說明中，但是相比之前的帖子，我覺得在1.34之後，Cargo被提及的次數變少了。Cargo變更多是工具鏈變更，因此，工具鏈數據最近無甚波動可能正是為此。這也沒什麼，這個數據是發佈聲明的閱讀數，但是值得一提。同樣，我認為編寫穩定庫的標準也隨著時間的推移發生了一些變化，全面性時強時弱。
上面已經提到了這一點，但是為了完整起見，Rust發佈的結構意味著將變更內容納入發佈內容的標準不是一成不變的。如果發佈的版本較小，則可能會包含較小的更改，而如果這些功能變化在大的發佈版本中時，則可能根不被提及到。如上所述，我認為這是否定我的假設的重要因素。
我認為未來的研究很有趣。我最初試圖跟蹤棄用和穩定性修復，但是穩定性修復並不經常發生，因此不值得討論。在這42個發行版中，有7個穩定性修復。這是未來研究的另一個弱點/領域，因為我沒有包括修正點發布，只有1.x.0版本。本來可以引入一些穩定性修復變更，但這會帶來很多隨機噪聲，而穩定性修復變更發生的情況並不多，所以這就是為什麼我忽略它們的原因。而且，穩定性修復發生並不規律，因此時間會變得有點滑稽……無論如何。棄用的理由也很難追蹤，因為棄用的理由並不多，而且有時候很難說某個功能被棄用是因為合理性問題還是其他原因。
我添加語法的標準是否正確？我認為一個有理智的人可能會說“不”。如果你您有一些特殊情況，並且要使其更加通用，則有一個很好的論點，即它是在消除限制，而不是添加功能。但是，理智的人也可能會說你添加了一些內容。我認為這不是我分析的核心，因此我認為做出這一決定很好，但是如果你您不同意，你可能不會在意這一部分的結果。
這種分析並沒有涉及到我認為很重要的東西:生態系統與語言本身。我只在這裡跟蹤Rust發行版本身，但是大多數Rust程序員使用很多許多生態系統庫。當人們談論Rust中的混亂時，他們真的指的是生態系統，而不是語言吧？從某種意義上說，這樣做是正確的：Rust具有一個小的標準庫，這意味著你必須大量使用外部軟件包。如果這些變動很多，那麼它在語言本身變動是否比在外部庫更好？
Rust 是否有一個小的標準庫？42個版本中有962個更改，每個版本將近23個更改。它們很多很小，但也是變更。也許Rust有一個很小但很深的標準庫？由於連貫性，我可能會認為這是對的。標準庫到底有多大？我僅在設計理念方面看到過對此概念的討論。我從未見過這樣的數值分析。有這樣的討論嗎？如果你知道，我很想聽一聽！
我認為標準庫更改主導總更改頻率有很多原因。首先，博客文章的這一部分往往是最完整的，也就是說，在全部更改中，與其他類型的更改相比，更多的標準庫更改使其成為博客文章。為什麼？好吧，這真的很容易衡量：統計穩定的內容，並將其放在帖子的大列表中。這也與如何衡量這些變化有關。比如，當將一種方法添加到每種數字類型時，相當於對5種類型（u8+ u16+ u32+ u64+ u128）變更，這可以視作5個變更，雖然理論上只是一個變動。
這就引出了另一個關於標準庫更改的問題：Rust1.33附近的奇怪峰值是怎麼回事？嗯，我們在Rust 1.31中添加了const fn特性。實現該特性之後，我們可以在標準庫中建立一些函數。最初的巨大變化落在了1.33。該特性繼續推動1.33之外的變化;const fn在1.31中最初的發佈是非常有限的，隨著它的擴展，更多已經存在的功能可以在const中實現。
總之，儘管我仍然相信Rust已經大大降低了其變化速度，但我認為並不是所有人都同意我的觀點，這是完全有意義的。從某些指標來看，我完全是錯的。
原文鏈接：
https://words.steveklabnik.com/how-often-does-rust-change
本文為CSDN翻譯文章，轉載請註明出處。
☞“谷歌殺手”發明者，科學天才 Wolfram
☞漫畫：“哈夫曼編碼” 是什麼鬼？
☞數據庫激盪40年，深入解析PostgreSQL、NewSQL演進歷程
☞黑客用上機器學習你慌不慌？這7種竊取數據的新手段快來認識一下！
☞超詳細！一文告訴你SparkStreaming如何整合Kafka！附代碼可實踐
☞Libra的Move語言初探，10行代碼實現你第一個智能合約
