- 主题:rust社区大事件：actix作者不干了
Raph Levien 也表达了一些观点
https://raphlinus.github.io/rust/2020/01/18/soundness-pledge.html
The pledge
I propose the following as the basic form of the soundness pledge:
“The intent of this crate is to be free of soundness bugs. The developers will do their best to avoid them, and welcome help in analyzing and fixing them.”
这样倒是也好，省得双方互相看不顺眼……
【 在 ilovecpp (cpp) 的大作中提到: 】
: 我想说Working on open source projects should be rewarding也应该包含提patch。断然拒绝patch，特别是别人花了很多时间的patch，肯定会引起负面情绪，不论理由对你来说多么显然。
: 比如Linus Torvalds，Lennart Pottering，特别是后者拒绝让systemd兼容非Linux系统的patch。区别只是这两位非常能喷，每次都喷回去。
: 当然，repo你管理嘛，最终你说了算。
: ...................
--
FROM 122.59.30.*
没必要那么排斥 unsafe，有时候为了效率，有时候是不用不行
这个 actix web 为了效率在内部使用了一些 unsafe，在接口上并没有暴露，
在内部作者自己来确保正确。
编译器是来帮程序员的，能够非常确定正确性的时候，且有额外好处（性能），
那就 unsafe，我毫无心理压力。
那个 pr 貌似唯一的目的就是去掉 unsafe，而且还很可笑的声称拥有版权。作者
或许是对这个项目投入很大，有感情，终于忍不了了。这东西是他自己的，喜欢
怎样就怎样，有 unsafe 洁癖的人看不惯，让他们自己 fork 去，完全不用动气。
【 在 eGust (十年) 的大作中提到: 】
: 不满意的人挺多的
: 个人也不太喜欢作者的做法。毕竟用了 rust 好处就是利用编译器检查健壮性，如果搞一堆没必要的 unsafe 那干嘛不去用 c/c++？如果我选的话，会避免用使用了大量 unsafe的库，但是不至于跑去喷作者不配写 rust……
--
FROM 101.112.222.*
开源很大一个问题是作者无欲则刚，但是刚的合不合适，那就是另外一回事了。
但如果作者有想让大家用起来的欲望，他就不刚了。但是欲望的达成想不付出代价是不行的。越大的欲望代价越大。
有些代价可能作者并不乐意付出。面对代价，商业软件用金钱让你低头，你不低头可以找个会低头的人来继续开发。开源的就可能出现作者放弃了这个欲望情况
【 在 ilovecpp 的大作中提到: 】
: 我想说Working on open source projects should be rewarding也应该包含提patch。断然拒绝patch，特别是别人花了很多时间的patch，肯定会引起负面情绪，不论理由对你来说多么显然。
: 比如Linus Torvalds，Lennart Pottering，特别是后者拒绝让systemd兼容非Linux系统的patch。区别只是这两位非常能喷，每次都喷回去。
: 当然，repo你管理嘛，最终你说了算。
: ...................
--
FROM 103.91.176.*
把unsafe改为__fast如何？
【 在 ilovecpp (cpp) 的大作中提到: 】
: 嗯挺好。其实一部分问题也是unsafe这个名字就不对，既不正面，也不正确。编译器只能证明type safe，不是说你这笨蛋编译器证不出来的就是unsafe。
: 应该叫human-checked
--
FROM 36.106.167.*
这个可能不同用户不一样。假设我只想要编译器帮助检查我写的代码，而经过时间考验证明安全性还不错的库，我并不很在乎它有多少unsafe，或者干脆就是C代码，比如libc, kernel。也合理吧？毕竟我新写的代码还没有机会被时间考验。
【 在 eGust 的大作中提到: 】
: 不满意的人挺多的
: 个人也不太喜欢作者的做法。毕竟用了 rust 好处就是利用编译器检查健壮性，如果搞一堆没必要的 unsafe 那干嘛不去用 c/c++？如果我选的话，会避免用使用了大量 unsafe的库，但是不至于跑去喷作者不配写 rust……
--
FROM 140.207.23.*
没什么关系。
这部分代码是“应该是安全，但编译器证明不了它安全，但我人工检查认为它安全”。fast同样概念上不正确。
【 在 tgfbeta 的大作中提到: 】
: 把unsafe改为__fast如何？
--
FROM 140.207.23.*
我是说，春秋笔法在PR方面听起来好一些。
【 在 ilovecpp (cpp) 的大作中提到: 】
: 没什么关系。
: 这部分代码是“应该是安全，但编译器证明不了它安全，但我人工检查认为它安全”。fast同样概念上不正确。
--
FROM 36.106.167.*
虽然不太懂，但我觉得哥德尔应该已经解决了这个问题：完备性是证明不出来的
unsafe 也可以当 unprotected 来理解，而且这个关键字也已经广泛在其它语言中使用了，没啥不妥的
【 在 ilovecpp (cpp) 的大作中提到: 】
: 嗯挺好。其实一部分问题也是unsafe这个名字就不对，既不正面，也不正确。编译器只能证明type safe，不是说你这笨蛋编译器证不出来的就是unsafe。
: 应该叫human-checked
--
FROM 122.59.30.*
人家的原话是
I license it under Apache-2.0 OR MIT, though I don't consider it to be creative enough to be copyrightable
自己觉得并不够声明版权
另外社区对 actix 的批评是不必要的 unsafe，并不是那种或不得已的、或导致显著性能损失的 unsafe。从评论里看，actix 减少了很多 unsafe，但对 benchmark 几乎没有什么影响。而且针对这个特例，也的确给出了会 panic 的情况
【 在 iRoNcOoL (人在胖 天在看) 的大作中提到: 】
: 没必要那么排斥 unsafe，有时候为了效率，有时候是不用不行
: 这个 actix web 为了效率在内部使用了一些 unsafe，在接口上并没有暴露，
: 在内部作者自己来确保正确。
: ...................
--
FROM 122.59.30.*