（上一句话，应该加一个狗头）

对以下内容的回复：

(忽然想到未来可能是NLP的天下)

……

“你已经是一个成熟的电脑了，该学会自己找需求自己编程自己调BUG自己发布自己赚钱养家了……”

对以下内容的回复：

是的，我们说的AI，其实内涵不同。

你描述的更多是现在还占主要的训练阶段/原型验证阶段的工作。

我描述的更多是未来可能的运行状态。

关于这块，我已经拉了一个群，做长期跟踪。

其实我更看好另一个（至少目前不存在的）方向，比如脚本+编译+证明

使用脚本语言给出原型（脚本比Rust开发起来快很多很多，而且不用与mut进行斗争）

然后使用编译手段将脚本用类似ZCA的方法转化成可以编译的语言（可以转化成同样没有gc的C，未必是Rust——毕竟转化这一步，（未来）更聪明的程序或许会帮助我们分析哪里有double free/data race）

最后，使用形式化证明的手段证明程序不会越界/溢出/...

.

对通用的程序，形式化的证明相当困难（因为停机问题存在）

但对特殊的程序（只有for循环的），证明其能否停机根本不是一个问题。

Rust的目标其实是保证，对通用程序，存在一个比较safe的方法（尽管有些时候不得不unsafe满天飞）

但事实上，至少对目前机器学习的框架，Rust的形式化是完全没必要的。

.

毕竟我们一共就做五件事

• 构造模型（搭积木，这个积木一般会一直保留到进程结束，所以，我们甚至可以用static声明它）

• 读取数据（这是iter，一般而言，都是大家写好的……哪怕你想发论文都不能改这一步）

• forward pass获取结果（由积木决定，没办法绕开积木进行定制。）

• backward pass获取梯度（由积木决定，没办法绕开积木进行定制……如果这个能改深度学习的框架会大改）

• 最后送optimizer更新参数（一般都是大家写好的，如果不发论文，没必要改这个。）

——这几步中，无论哪一步，都不像unsafe

但送去Rust

• 首先，积木至少要绑定一个mut，如果遇到输入大小不恒定的时候，我们还需要指定额外的申请/释放显存的代码（python脚本也存在类似问题，但我们并不关心python脚本是如何实现这一点的）

• 读取数据，如果大小不恒定，我们仍然需要手动申请/释放内存（python表示这个它也可以自己做好）

• forward pass获取结果（如果写Rust，由于需要跟cudnn交互，必须使用unsafe……没办法“表现”出Rust的安全性）

• backward pass获取梯度（同上）

• 最后送optimizer更新参数（同上）

如你所见，最主要的部分都是unsafe……这就是我为什么不看好Rust的原因了。

（又不是没人写Leaf）

对以下内容的回复：

其实化繁为简，最后就是落脚到rust与c++之争。当rust市场份额超过c++那一刻，就是我这个断言趋势清晰的那一刻。

也许需要10年，也许是15年。

你要相信，对于大规模的AI工业市场竞争来讲，真正最后留下的一定是性能和安全兼顾最强的那个/组方案。rust是非常有力的候选。

其实你并没有正面驳斥我的观点，甚至可以叫我的观点的补充 😃

我还以为MXNet绑上了Rust呢…… 在最快的深度学习引擎没提供对Rust的原生支持之前，我并不看好Rust能在AI上做出什么贡献。

你所谓的AI，跟实际的AI，跟未来的AI都有区别。 你以为的AI，有现存AI的计算需求，跟未来AI的安全需求 但现在的AI都是机器学习弄出来的，安全性（甚至可以说）远高于Rust……毕竟现在的深度学习就是搭积木，在搭积木之外的关键代码都是需要用nvcc编译的。对Rust来说这就是成吨的unsafe——而其他语言至少有意识对这些unsafe提供几个gc

未来的AI可能就是policy based的那种版本……或许在安全上有问题，但是在性能上不会有问题。 无论多好的电脑，用多好的CPU/GPU，用来玩gba模拟器里面的超级玛丽，帧数都差不多。

对未来的AI，用不用Rust可能就是想0.00001秒跟想0.000001秒的差距 比例不小，但实际差距没那么多。

AI引擎涉及巨量计算，自动驾驶汽车更是需要巨量实时计算。对性能的追求怎样说都不过分。

对性能的极致追求肯定会与编程安全性产生矛盾。

故Rust是解决这个问题的不二选择。