@DigitaIOcean 感谢，不过我看过了。

我的观点还是一样：百度能运营这种可能造成致命危害的自动机械，本质上和电梯制造商差不多。电梯重大人身事故怎么判，这个就怎么判。

可参考： https://www.thepaper.cn/newsDetail_forward_23184910

现在娱乐圈进化为饭圈了。你就说热不热闹吧

@Nasei 你是想找一个 https://github.com/spf13/viper 那样的库吧？这种大而全的库我确实没看到比较好的，clap 本身不支持，还在讨论中（虽然已经讨论 6 年了）。

可以用 clap + config + clap_config 来做，总共也就多写一行代码。也有一些相对不流行的包实现了多来源参数合并，例如 hyperparameter 、argone 。

@sagaxu 不支持，干啥都要写 For 。当然也可以自己写一个 Map 之类接受闭包的函数，但 (1) 我没找到过好用的工具包；(2) Go 的闭包函数不是零成本的，会损失性能，高性能场景慎用。

@w568w 补充一句：不是说 go 不好。只是这种场景下，rust 确实领先 go 太多了。

@kk2syc 稳定是稳定，但是大多还有一堆报告不兼容性或者 bug 的 issue 没修，作者基本也摆烂了……

另外，楼主问的是 Rust 和其他语言相比的优缺点吧？

1. 论跨平台，静态编译方面 Rust 早就超过 Go 了。还认为「 Go 的跨平台是独家优势」的该更新更新观念了；

2. 论易用性，Rust 有 clap 之类的神器，一键生成 help message 、schema 和类型校验，不像 Go 每个参数的解析要写一些像 python argparser 那样的 boilerplate 。而且 Go 的哲学是 verbose is better than implicit ，适合写网络解析之类的通信逻辑，对命令行工具很不友好；

3. 论生态，Rust 的命令行解析器和 CLI 基本都在活跃更新，而且都卷出新高度了（ https://github.com/rosetta-rs/argparse-rosetta-rs ，看这里，甚至在卷毫秒级的解析性能和内存占用）。

作为被 Go 折磨的人，我实在不推荐这种需求上 Go 。

目前无人驾驶车基本还是有驾驶位的。像 Tesla 那种级别的自主驾驶，自然是罚驾驶员。我猜楼主说的是完全无人驾驶、乘客没有操作机会的那种。

我的观点是，作为可能造成致命危害的自动机械，可类比：

1. 商场自动扶梯夹人事故：商场和厂家质检部门负责；

2. 电梯故障困人：负责定期维护的厂家负责；

3. 露天广告牌砸到人：施工单位和广告牌承包商负责。

@wwqgtxx 是的，于是我的代码就不能通过编译了。

最通用的方式：<div id="mycode"> ... </div>

@w568w 缺失->却是

clap 确实神器。

关于 Go ，不妨自己看看现在 Go 的 Argument Parsing 库哪个符合 GNU 规范的、哪个是在活跃维护的。每次找 CLI 相关库，一看 star 一堆，最后提交时间缺失「 4 年前」，都感觉 Go 的生态有一种垂垂老矣之相。Rust 这边就欣欣向荣多了。

另外说 Go 跨平台编译无出其右的…… 说实话，这套说法在 Rust 出来之前我还相信，现在 Rust 的编译体验比 Go 好多了，起码不用在那里摆弄 net 和 libc 的链接问题，还有纯血 Rustls 之类的系统替代库，实现一键全静态编译。

利益相关：臭写 Go 的，写 Go 比写 Rust 多。

1. 「一次性按照科学方法设计好」是谣言。

QWERTY 键盘基本是逐步演化而来的，一段时间改一个按键布局。具体可见上面科普中的参考文献和历史资料；

2. 「 QWERTY 就是为了避免打字机卡键」或「为了降低打字速度」是谣言。

「为了避免卡键」疑似可能，但仅仅是演化过程中做部分修改的一个考虑因素。否则，为何按键频率极高的 ER 组合被设计在一起？「降低打字速度」客观上起到了这样的作用，但说这是设计目的，则是纯粹的胡扯了；

3. 之所以 1 、2 这些谣言遍布广，就是因为没人愿意认真听和传播一个近五十年的键位演进历史，多枯燥啊。「避免卡键」四个字一下就说完了，朗朗上口。

4. 求真务实地说，QWERTY 键盘没什么神秘来历，就是一条最无聊的、设计师们考虑当年打字习惯和使用方便而来的复杂演变过程。

Only Google Can Do!

这是给 Firefox 送子弹啊

@qbqbqbqb 也许吧。但楼主看到却没有回复我这两条，也没有更改自己的问题，那就默认楼主知道自己在说什么吧。

@w568w #12 再补充几点：

1. SHA256 不慢。一般人说「 SHA256 慢」，也不是因为算法本身过于复杂；
2. 不仅 SHA256 没有，RSA 也没有「几百万次循环」；
3. 摘要算法不存在常规意义的「破解」一说。一般说有安全问题都是指证明了不具有抗碰撞性、抗第一原象性（这是一般人理解的「破解」，即从摘要值恢复原文）和抗第二原象性。目前基本没有摘要算法被「破解」。

更多摘要算法介绍可以看这篇： https://thiscute.world/posts/practical-cryptography-basics-2-hash/

@valord577 我猜你说的是 RSA ，一种加密算法。SSH 的安全加密是 RSA 算法完成的，SHA256 只是用来确定指纹。

另外 SHA256 是「摘要算法」，不是用来加密的，和加密算法除了都有「算法」俩字，根本没半毛钱关系。在不改变原义的情况下，摘要算法永远是越快越好、越优化越好，所以才有那么多硬件加速。

最后，SHA256 （包括很多摘要算法）本身根本没有什么「几百万次循环」，那也是加密算法才考虑的。不要被楼主一知半解的提问误导了。

首先一个根本性错误：SHA256/512 依然是速度优先的，根本没有什么「循环 100000 次」的过程，中间每个 chunk 最多也就循环 64 次。

对于「循环 100000 次」的问题，楼上说得很清楚了：次方还是对一个数做 N 次乘法呢，你能化简次方运算为 1 次吗？

回到正题，加密循环可参考这篇文章： https://blog.csdn.net/u011583927/article/details/80905740

总的来说就是右旋和位运算叠加的过程，原理上来说因为要读取整个文件（而不是什么「循环 100000 次」），不能化简。