不是，这也要阴阳怪气一句「神奇的土地」，我寻思别人说啥了？楼上又敏感了？

----

楼主似乎有点钻牛角尖了，而且似乎不愿意读别人发的法律，不管答啥都怼人家「驾照」「扣分」两字。

楼上的几位说得非常清楚了：

1. 违章谁负责：公司负责；

2. 怎么负责：追究公司民事或刑事责任；

3. 怎么追究：目前判例太少。从现行法律来看，无外乎 (1) 公开道歉和公示，勒令整改 (2) 向受害人和相关受损部门经济赔偿 (3) 吊销公司运营资格 三个等级；

4. 具体到哪个部门：公司作为一个整体接受处罚，别把问题搞复杂。以上几种处罚和补偿措施和个人没有关系。非要说的话，公开道歉当然是公关部门去做，整改是工程部门去做，经济赔偿是财务去做，吊销运营资格那更是和某部门没关系了，全员解散；

5. 具体到驾照：无人驾驶汽车和汽车都是一种自动机械，只不过汽车需要一个操作员——司机来驾驶，所以才有了「驾照」的概念，不是因为有「驾照」才有「车」，别把逻辑关系搞反了。无人驾驶汽车法律领域也许（只是也许！）会有类似「企业驾照」的东西，但目前还没有，相关法规待完善。

@daliusu @RheatiN 我的英语水平不重要，我想表达的是：陌生的语言有利于强迫人规范表达，同时也能促进逻辑思考：问题里的英语换成 日本語 或 Espernado ，对我来说结果一样。

@passive @luckykong 有可能。不过书写中文对我来说就已经能让我补齐逻辑上的漏洞了，只是英文给我的感受更强烈。另一方面，我觉得其实学习英文也是杜绝中文病句和逻辑不通的一个很好的方法，因为义务教育阶段只有外语课会从语法角度出发教你语言嘛。

1. 因为懒，没有 KPI 不想更新换代；

2. 因为技术不行，负责 Linux 的开发太少；

3. 因为这是响应号召。虽然有「信创」大旗在前，但信创基本都是打包好的固定 Linux 环境，根本没考虑 freetype2 升级的问题。也许他们自己到现在也在用旧版 freetype2 ，因此没遇到任何问题。

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