Safe or Unsafe —— 如何管理「不可控」

今天最大的事件就是 「actix-web is dead」。简单来说就是 Rust 系性能跑分最好的 web 框架 actix-web 因大量使用 unsafe 导致其作者 Nikolay Kim 被 「safe 教徒」喷自闭了，愤而将 actix-web 转移到私有仓库。

要说原因，顾名思义就是 「unsafe」 不可控、不安全。而「safe 教徒」觉得有「unsafe」就是不行。从结果来看，大家会觉得这群「safe 教徒」很蠢，但是其实编程界有大量的这种 「教徒」，但是他们纠结是其他东西而已。

有那些不可控

我们来看看常见的「教徒言论」：

1. 不能使用「宏」
2. 不能使用「goto」
3. 不能使用「全局变量」
4. 必须是「纯函数」
5. 「多线程」不安全
6. 不能使用「eval」

「教徒」们在害怕「不可控」。

不可控的危害

「不可控」带来的危害要是一点：「不可预期」。换成人话就是，你写的代码出 bug 就跟摇骰子一样，什么时间什么地点会出问题完全不可预见，甚至你没有办法复现。比如 Rust 里面的 unsafe 主要避免的就是你的代码跑着跑着不知道什么时候突然来一个了段错误，而你查了一个月也没复现出来这种情况。

想象一个情况，你的代码你自己、测试、公司里面的大家跑起来都没问题，但是用户里面有千分之一的人会出现错误，并且这部分人的硬件、系统等都均匀分布。当你老板在开发布会现场展示的时候当场翻车，你是一种什么感受。

其实这些在写「业务代码」的角度来看，这些不可控是需要避免的，因为：

1. 业务代码并不需要使用这些「底层技术」
2. 写业务代码的人也并没有很好的「底层技术」能力

并且，「不可控」具有传递性。如果你一行代码「不可控」那么不过不对他小心处理，「不可控」的属性会传递至整个模块甚至整个系统。

没有约束所以灵活

为什么会出现这些「不可控」？编程语言设计的时候为什么不把这些「恶魔」全部去掉？

因为「不可控」只是「灵活性」的「代价」。

因为没有「约束」才让很多语言特性非常强大，我们刚刚提到很多「不可控」特性都具有非常强大灵活的能力，而没有了足够的「约束」就这些特性变得「不可控」。

管理不可控的边界——标记与隔离

凶猛的野兽可以关进笼子里，也可以带上镣铐替我们打仗。我们有没有一些方法能让这些「不可控」但是强大的特性为我们所用？答案是 —— 「标记与隔离」。

以 Rust 为例，unsafe 这个关键词是干什么用的？是给你的程序打个耻辱表，证明你的程序耻辱吗？并不是，而是告诉你：

1. 能力越大责任越大，请小心处理。
2. 如果你的代码出现了奇怪的段错误，请来这里找错误。

这个 unsafe 就是「标记」，通过一个显示的标告诉你这个代码不安全。再举一个例子，java 的方法需要显示「标记」会抛出的错误也是同理，告诉你/编译器这里可能会出现xxx问题你要处理。这是第一步，标记。

除了以外，另一个手段是「隔离」，将「不可控」和「可控」隔离在不同区域。比如我大 Haskell 将副作用用 Monad 隔离。这个的作用和理念就是，在「可控」的代码里面不调用「不可控」的代码，在代码运行时，「不可控」的代码来调用和执行「可控」的代码，并且尽量保证「不可控」代码的部分缩小。

1. 「不可控」调用「可控」—— 避免「不可控」传递
2. 减小「不可控」范围 —— 减少出错的范围和概率
3. 入口是「不可控」代码 —— 因为入口要处理 IO

强调！！！
Monad 是一个「结构」，没有什么纯不纯、副作用不副作用的概念。以 IOMonad 为例，IOMonad 没有什么纯不纯的概念，但是 runMonad 的时候是有副作用的。main 的类型是一个 IOMonad 「结构」。
（以前被一些前端的半吊子函数式水平伤害过……

写的抽象了点，有些设计经验的小伙伴应该能理解什么意思，一时间也比较难找到好的例子就先将就看吧。