作者 | 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行代码实现你第一个智能合约
