@LosLord 你说 GC，Rust 是直接控制生命周期，也不算多么底，说到底还是语言控制资源分配行为模式。
GC 就是引用计数（还是可能泄漏）或者标记（对异步不算太友好），然后就是两个方法结合。
而 Rust 就是通过各种规范要求引用计数恒为 1，对原型真的很麻烦，尤其你还没把程序逻辑厘清楚的时候你还要同时考虑生命周期，是人干的事吗？我认为这就是上面说的 “适合重写项目”，重写的时候程序逻辑已经很清楚了；另一种场景大概就是有专门的设计程序逻辑的流程甚至专员（架构师？）。
所以其实应该是大量代码外包给各种不同公司或者是 Firefox 这样的大型多人协作项目适合的语言？因为代码质量控制比较困难，至少能从语言层面保证不要产生泄漏就很好。我没多了解，只是看到有人吐槽 Rust 生命周期就去看了下。

多维链表简单插排不就行了？
要觉得这样效率不行链表部分换堆

@huihoo 编程语言处理过于伪命题。这个分类也不叫编程语言叫形式化语言。
LL/LR 还不够用吗？至少直接处理 AST 比处理字节流好多了。

@MLLB 版权所属可以爬虫爬源站，我第三段其实是补充第一段的。
大致流程：
1. 原创作者提交网站目录 —— 验证网站所属 —— 设置一些参数 —— 定期爬取加入数据库
2. 中小网站请求严格审计 API （用于设计上属于发布原创作品的网站）—— 搜寻数据库
2.1. 若有匹配：认为抄袭 —— API 返回 rejected —— 上传者可认为有争议 —— 人工检查
2.2. 若无匹配：认为原创 —— API 返回 accepted —— 网站发布
3. 中小网站请求宽泛审计 API （用于设计上**不**属于发布原创作品的网站） —— 搜寻数据库
3.1. 若有匹配：认为转载 —— 确认参数
3.1.1. 若原作者要求不可转载 —— API 返回 rejected —— 上传者可认为有争议 —— 人工检查
3.1.2. 若原作者要求条件转载 —— API 返回 conditional —— 网站自行确认是否符合要求
3.1.3. 若原作者要求手动检查 —— 进入检查队列 —— API 返回 created （可能是 http201 ） —— 原作者检查、确认 —— accepted 或 rejected 或 conditional
3.2. 若无匹配：认为原创 —— API 返回 accepted —— 网站发布

其中 2. 可以稍作修改，在 accepted 同时加入数据库。

@coderljx 搜索引擎，请
我估计下下来的本来就是错的，不是 pdf 格式
我估计是 HTML 所以先记事本看一下也行。

……我觉得一个模式是支持反查版权所属，并提供收费 API。
顺便还能帮助中小型网站符合欧盟新版权法。
——
另外一个是版权守望，订阅过后对于原创的所有图片对于一些网站上的侵权使用作提醒。
——
如果你只是保存而不提供图片本身，甚至只保存反查用的索引数据和源地址，仅提供反查并且结果给外链的话，应该不会触及多数国家版权法，并且你的存储和上行需求是比较低的。
那么上面就可以用爬虫去爬了。
但是可能会产生 EU 新版权法定的搜索引擎税。

Email 不可行，git 留的邮箱是为了这段代码留的，而不是为了邮箱的主人留的，只会招来嫌弃。

在？看看 HEX dump ？

@autoxbc 我觉得还不如社区协作，充分标记 WIP。

@CHYK 至于千年虫，我感觉更像是重构时 **意外** 解决的，这我有过不少经历，事后的感觉就是 “欸？这么说我原本的代码是有 bug 的？”。
可能某些时候算是代码健壮性的一部分，健壮性也确实是重构的目的之一，但不是靠重构本身完成的，而是重构期间形成的可读性。有人说：没 bug 的代码只有非常复杂以至于看不出 bug 和非常简单以至于看出没 bug 两种。重构的一个目标就是尽可能将前一种变成后一种。

@CHYK 我同意你说的 “以重构的名义”，但我不认可你说的 “实际也是重构”。
你这个叫 “重架构”（ restructuring —— 我瞎编的，不清楚有没有这个词，或者更正确的词）和技术性调整而不是 “重构”（ refactoring ）。甚至可能同时进行重构和其他事情。
不要同时做两件事，更不要在同时做两件事时以为自己在做一件事。
一个简单的判断：重构应该能够在 20 分钟内完成（或者按自己的番茄钟时间），并且这 20 分钟就好像从未存在一样消失了。

@CHYK 我觉得你说的根本不是重构，而是修改。
重构的核心不是不发生任何改变吗？重构完除非调 commit 或者记得原本的代码否则根本不可能发现重构了。
更何况重构不可能解决、也不太可能帮助解决千年虫问题和年号问题，要能解决一定是用了未定义行为，或者编译器或者运行时有 bug。

看完感觉说的 “重构” 都不是一个事。

我觉得重构其实根本不需要任何的理解和支持。
某段代码（因为需求原因）需要作修改的时候就直接顺便重构掉了。

@HustLiu 我的第一主张是防 root 不能防患，并且放患防用户，甚至因为 “存在某种防患机制”（尽管这个防患机制完全不能防患）而导致粗心大意，造成更大的患。—— 有问题请重读九年义务制教育，或者前往附近的三甲医院检查眼科。
这点上我有教训，可惜已经把原本的事故忘了，只记得这个教训本身，不然还能给你讲讲。
就举个浅显的例子，alias rm='rm -i' 为什么不好，这已经被多个论坛和博客讨论过很多次了。

如果你想要反驳我，那么你能说且只能说为什么防 root 能够防患。

@HustLiu 不清楚你是哪国人？砸店或类似行为，甚至相关的威胁都没见报啊。
我上面也举了保险的例子，你不仔细看看？
“这就相当于给特地不关门引诱窃贼上门然后实施抢劫的人理赔，然后给忘了关门导致失窃的人拒保。”
睿智操作，有什么辩护的必要吗？你是想把微信的 “蠢” 给扭曲成微信的 “坏” 吗？

一方面，扩展 decentraleyes 可以进行大多数常见资源的重定向。

- 支持的网络：Google Hosted Libraries, Microsoft Ajax CDN, CDNJS (Cloudflare), jQuery CDN (MaxCDN), jsDelivr (MaxCDN), Yandex CDN, Baidu CDN, Sina Public Resources, 及 UpYun Libraries。

- 打包的资源：AngularJS, Backbone.js, Dojo, Ember.js, Ext Core, jQuery, jQuery UI, Modernizr, MooTools, Prototype, Scriptaculous, SWFObject, Underscore.js 及 Web Font Loader。

能够直接覆盖掉这些 CDN 的这些地址，替换为本地版本。

如果不太复杂反而自己按需拓展的 INI 会更好。
YAML 方便的就是这些解析器不需要自己拓展。
另外，我觉得一个大问题是结构太松散导致眼 parse 费力，尤其是 array 套 object 时。