更新：actix-web已经找到了接手维护者。

新的维护者看上去是一个比较靠谱的开发者，看到他也参与bastion这个项目，该项目旨在用Rust实现一个类Erlang VM(BEAM)的东东。感觉actix-web交给他还是比较妥当的。

也值得庆幸的是，Nikolay终于想通了，虽然他不再继续维护，但至少心情不会再郁闷了。

这是ripgrep的作者Andrew Gallant写的这篇文章，分享了他十几年参与开源项目的看法和经验，值得一读 ，里面包含了如何处理开源中遇到的各种负面情绪，如果有朝一日你也做了开源项目，这些经验也许能帮助你。Free and Open Source Software (FOSS)。

关于此次事件的补充：

真的，不用给PTSD洗地了。

这次确实UB了，但不是因为UB的问题作者才暴走。作者开始是merge过PR，后来他们觉得还有问题，然后继续提了个补丁。但是这次作者觉得这个补丁太没有创意，就没有merge。然后说了句：“这个补丁太无聊。”，然后他就去思考这个issues的更好的解决办法。

但是这帮人去Reddit发了个贴，声讨他那一句“这个补丁太无聊。”，还有人攻击他，“你还是别写Rust了”。这还不是PTSD？

作为作者，思考更好的解决问题方法，总得有时间和空间吧？需要发到Reddit进行攻击吗？人谁还没个冲动的时候？issues删掉肯定是他的问题，但我们应该给予足够的宽容，不回头看看他做了多少努力和付出？他在2018年6月份就已经和unsafe做斗争了，这一年半的时间也是深受那些PTSD的困扰，这次估计是没忍住。我唯一关心的是他为什么要换成UnsafeCell，他没有解释，但可以猜到，他认为那个只是内部调用了两次不会有大问题。既然发生了UB，估计他也没有搞清楚为什么，需要时间消化找到更好的方案。以此来推断他的人品，或者下定论，贴标签，都是不合适的。我本来做actix是因为有趣，想去创造，想要尝试Rust的潜能极限。

但现在我为什么这么不开心呢，生活本该不必如此。

再见了，各位。

————总结自 Actix 作者Nikolay Kim(又名 fafhrd91 )的文章

想要正确看待这件事，你首先需要理解Actix作者的初衷。(本文结尾也附上了那篇文章的翻译。)

前因后果

自从Actix问世以来，挺受欢迎，毕竟，Rust的Web框架不是很多。

在性能上屡屡霸榜 techempower 的性能测试榜单。

也不知道从何时起，Actix中使用Unsafe的情况被大家挖掘了出来。

最开始是Nikolay做出了积极的改变，我在做Rust日报的时候，清楚地记得，他看到反馈接下来的几天，积极地宣布自己改善了多少Unsafe的问题，剩下多少问题，是为了什么目的。

然后事情就这么安静地过去了，空气中传来了快乐的气息。

但现在回想，也许他当初积极的态度，为今天的事情埋下了伏笔。

也忘记了过了多久，有人继续在找Unsafe的问题，也不管Unsafe代码到底会不会产生UB或Bug，但凡看见Unsafe可能就很敏感。就像是Unsafe PTSD患者。

对于这些情况，Nikolay选择了无视。这正好和他最初积极响应修改Unsafe的态度相反，所以刺激了某些人，在Reddit上面发出了声讨贴，于是，大家提到Actix，提到Actix的作者就有了下面的标签：性能测试作弊者。

强行写Unsafe，别人提了意见也不去修改，自以为是。

我相信，如果换成任何人，心里都不会舒服。

Nikolay并没有义务给大家科普Unsafe Rust到底该如何使用。

但他的表现真的是那样吗？

当然不是，对于一些合适的PR，他是Merge了的。但是对于每个PR，他也会如是拷问。是真的解决问题了吗？

这是前因。

直到昨天，Nikolay收到一个issues，这个issues虽然被删了，但是据说在里面骂了Nikolay，而Nikolay还在思考如何解决Actix-web中的问题。

然后Nikolay 生气了，就把actix-web的库迁移到了自己私人仓库里。

我的看法：

很多人说 Nikolay 有点小气。但我不这么认为，去看看上面前因后果，换了谁也不忍受不了。

我从Actix 0.7开始关注并使用Actix做项目，直到Actix-web 1.0。

你们可以对比下 actix-web 0.7和1.0 的重构变化，你会看得出来Nikolay是多么用心在做这个项目。

他是带着自己的创意，想去完成一件作品，是想突破自己，也想看看Rust的潜能极限在哪里。结果被人打上「性能测试作弊者」的旗号，可悲不可悲？

来自官方和社区的声援：

矛盾的根源

其实，这件事的矛盾本质是大众对Rust的Unsafe不太理解造成的。我当时在写《Rust编程之道》的时候，最后一章标题是《不安全的Rust》，但是编辑看到这章标题跟我反馈，「Rust不是号称安全吗？为什么这里是不安全的Rust？」，于是我意识到问题所在，改成了「超越Rust的安全边界」。

我其实就是想表明，Unsafe Rust，是Rust的安全边界。世界的本质就是Unsafe的。你无法避免它。

还有人说，因为Unsafe Rust的存在，所以也不见得能比C/C++安全到哪里去？

Unsafe Rust确实和C/C++一样，要靠人来保证它的安全。但它对人的要求更高。

它也给了开发者一个Unsafe的边界，这其实也是一种安全边界。它把你代码里的雷区，显式地标记了出来。团队代码里review的话，可以更快地发现问题。这本身就是一种安全。

而反观C++，你写出的每一行代码都是Unsafe的，因为它没有像Rust这样明显的界限(Unsafe 块)。

以下是我总结的五条使用Unsafe的简单规范，方便大家做权衡：1. 能用Safe Rust就用Safe Rust；

2. 为了性能可以使用Unsafe Rust；

3. 在使用Unsafe Rust的时候确保不要产生UB，并且尽量判断其安全边界，抽象为Safe方法；

4. 如果无法抽象为Safe，需要标注为Unsafe，并配以产生UB的条件文档；

5. 对于Unsafe的代码，大家可以重点review。

针对这件事，Rust 核心团队Unsafe内存安全模型的负责人RaphJ也专门写了篇文章：

我给大家做了一个摘录，详细的去看原文：The Soundness Pledge​raphlinus.github.io《关于「可靠/安全」的承诺 (The Soundness Pledge)》

Unsafe 关键字具有特定的含义：这表明需要更多的推理才能证明使用代码是安全的。

在 Unsafe 块之外，编译器实质上使用在类型系统中编码的信息来证明使用代码是安全的。 在Unsafe块中，会允许某些通常被禁止的事情，例如读取和写入原始指针。 对于不太了解Rust的人，建议阅读Rust书中的Unsafe Rust一章。 否则，很多讨论可能会造成混乱。

在Rust社区的某些地方，人们倾向于认为Unsafe本身是很糟糕的，但是我认为这有一些微妙之处。 当然，用安全的Rust可以很容易地编写代码，使用Unsafe的方法获得一些可察觉的性能提升。但更糟的是，通过借用检查器来减少抱怨，这不是一个最佳实践。

然而，对于许多用途，尤其是与为其他语言设计的库或运行时集成，这是必不可少的，并且良好地使用它很重要。 其他有效的用例包括SIMD和基础数据结构的实现； Rust标准库具有良好的集合，但并不旨在全面涵盖所有可能的用例。

有时，避免安全性错误(UB)相当容易：只需在代码中的任何地方都不要使用“Unsafe”，并且不要依赖任何其他有安全性错误的库。 对于某些类别的问题，这是可行的。 通常，它是在性能和​​安全性之间进行权衡的，但是我还没有看到很多证据表明这确实是一种权衡。

在大多数情况下，Rust为您提供了实现这两种功能的工具，但是有时确实需要额外的工作。 Rust中的许多安全保证都是零成本的。 其他一些方法(尤其是数组边界检查)需要一定的成本，但是即使在安全范围内，普通的性能调整技术也通常很有效。 对此的一个数据证据是pulldown-cmark，它现在具有同类最佳的性能，但不使用不安全的方法(存在可选的SIMD优化，但是性能与默认配置几乎没有不同，这要归功于通过 Marcus Klaas de Vries)。

这篇文章很长，并且后面还列举了使用Rust和其他语言、库打交道过程中使用Unsafe的一些问题和看法，欢迎大家去仔细阅读，有欢迎翻译分享。

总的来说，我们应该建立对 Unsafe的正确认知：「Unsafe Rust是一个锋利的工具」。

对待Unsafe的态度是：

1. 对于那些知道如何正确使用Unsafe来完成目标的人，报以尊重。

2. 不要滥用Unsafe。

Rust库的可靠性承诺

为了避免出现同类的事件，RaphJ在上面的文章中还提出了一个建议：

就是在每个crate或框架中，引入这样的一句话：「“这个crate的目的是为了消除缺陷。 开发人员将尽最大努力避免它们，并欢迎在分析和修复它们方面提供帮助。”」

加这样一句话的原因在文章里有阐述：虽然几乎每个人都同意可靠比不可靠要好，但是不同的人对它的重要性有不同的优先级，特别是在编码工作和性能之间的权衡。大多数Rust开发者群体高度重视可靠性，但即使在其内部也存在显著的变异。我已经提出了一个承诺，一个真正的意向声明，我希望可以用来清楚地传达Rust工程的优先级别。现在，我是在邀请讨论，而不是提议把它作为一个正式的标志。

正是因为每个人对安全和性能的期望有所不同，所以最好在自己的框架或crate里加上，你们侧重的是哪一点？这样使用者自己可以判断。

Actix作者最后的发言文章

翻译(来自于Rust中文社区Jim，请大家不要在评论此文翻译的如何，不是重点)：新的一天，又一个该屎的unsafe风波，我已经麻木了。

断章取意的读评论这么容易，真是太有意思了。(尤其是母语非英语的人)写有清晰意图的评论又是这么难。怎么打补丁？ 很容易吧，直接，简单，一点都不用创意，一点也不用改多余的代码，目的就是把unsafe 去掉，多余的什么去根本的都不用多想哈。 我认为软件编程是一个世界上数一数二，最需要创意的工作，创意是人们爱软件编程的源泉。 特别是做一个实际的，世界人都能用的项目，这样的实际项目都有条条框框，需要创意才能满足的需求。这样的项目才有意思。一直在你挑战你能力的极限很有意思。 没有创意的修改方式很没有意思，(哦，那个作者终于不要这个补丁的版权了(好讽刺啊))。 我从来不是一个随便用unsafe的人。 我用它是因为我相信我的用法是unsafe但不影响我的安全性。不会有被黑的漏洞。我相信提出的这个问题的确属于mutable aliasing invariant， 我也很高兴有人找出来一个真正需要解决的问题。 我也希望解决这个问题，只是不是像这样解决，这个解决办法很没有创意。 要实在不行再用RefCell来解决。 比如我找到了一个我认可的解决方案，现在在master里，至少解决那个issue里面提到的一个问题。你们要是跨我的底线，至少要骂对。再说跨度也太没边界了。

维护大型开源项目一点也不好玩。总有人没礼貌，传播恨，大家都知道怎么写软件，却没有人愿意仔细做功课，读官方文档，想一想，更没有人愿意做贡献。看来大家都以为我们actix团队超级庞大，每天无所事事，经费更是张口就来。 (在这里仍要感谢这写默默支持我们的人)。比如 async await花了三周一天十二个小时，很累人的，发布后又有人抱怨文档没更新，我又要更新。 真是令人身心鼓舞啊！你们发现这个该屎的unsafe风波后发没发现，我在社区出现的时间 越来越少。真的，这么努力的你看到如此不体贴的评论真的感觉自己被背叛了。我也知道删issue 是个挺二的主意，但是最后两个针对我的评论真是气不打一处来。特别是我看到这评论前我还在想解决方案。我不该。

我写actix有三年了。我学到了很多，见到了好多新人，我找到了我心爱的语言，我想一辈子用。我找到了有意思的工作。但是损我项目的名声真是够了。我不认为我身心可以恢复了。我想Actix永远都是别人眼里的“一坨一坨的UB”，“跑分骗子” (我的tfb跑分是因为我想把rust的潜力都用出来，我争强好胜，我并不想把其他rust的项目比下来。所有actix 名下的项目，无论是actix-web还是 actix-net 我都花心思设计了，api也好，框架也好。每个项目我至少重写4-5次。我延伸了一些需求，一些新的写项目的方式与规律。我希望其他人看我的项目们的源码后收到启发，更上一层楼。现在我觉得支持actix没意思，在rust社区没意思。

我不干开源了。

备注： 我把actix-net 和 actix-web放到我私人的github上了。我会过几天做决定。我不想我的东西变成幽灵般的存在，要是有新的维护人员的话，他们必须明白怎么运作，那些已经或有可能忙着其他项目的人不合适。所以我现在的打算是把项目设到私人然后删除，跑分也会会被删除。除非有人有更好的主意。

所有事情终将结束，一路上很有意思但现在该翻篇了。生活本该活的有意思。

对于Nikolay的最终决定，我只能表示理解和尊重。

最后一句话，大家共勉：

No matter your opinion on the whole technical discussion people should be treated with respect.