@pence2019 ……没测试。。。那就先写测试对付其中看起来比较靠谱的部分当 KPI 吧，顺便可以辅助逆向出文档了。

存在清晰的对得上号的设计文档的部分，可以不需要加注释。
如果要重构，预计被重构掉的部分可以不动，先统一整理模块清单，安排重构计划。
剩下的注释按便于维护者和使用者理解为基准，能加多少加多少，力度看着办。
重构的工作量必须计算工时。
不配合的，要求提出替代方案和工作计划，被项目技术负责人和 PM 认可之前搁置计算该项目内的有效工作量；否则，可以自愿调岗。

@changjiangzzZ 有个面向未来的业务问题：如果能有非单一厂商提供技术支持的基于去中心化存储和信任的 IAM 服务可用，你可否预计会对以现在的形式提供 IDaaS 服务的厂商最可能有什么样的长期影响？

起码是正的。

https://github.com/drop-ice/dear-github-2.0
看戏，，，

本来我想转身就走的，但是看到中间一句“/common/cat”，我不得不给个回复。
加油，你不是一个人！

@jackmod 页游端游不一样，不要混在一起打啊……
（ EVE 狗头

@f056917 这家之前已经停服过一个也叫战双的游戏了。

回到主题，不限于 Rust，就是指通用目的语言的话，更长期的趋势不好说，但我预测应该迟早会“文艺复兴”——最终把 C/C++ 这样绝对意义上就不怎么好用而且可维护性怎么整都不咋地的方案给排除出包括系统编程领域在内的各个主流实现。
更长期地，DSL 可以从通用语言演化。我之前有粗略考虑过这方面的整体需求问题：
https://github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#judgment-on-the-general-purposed-language
我的结论是，要满足一般意义上的一桶浆糊的目的，基本上只能靠其它领域的通用语言实现，先从克服语言演进的障碍（更新和修改语言特性的现实工程问题）开始——像 Rust 这种被用户需求逼出来的包管理器这样的表面方案是远远不够的（现在依赖外部 shell 的整合方式也不是合理的方向）。根本地，这要求语言特性应能很大程度地“反射”语言 spec （注意，不说 Rust 这种连 spec 都没给的，大多数语言在这里仍然是用不靠谱的自然语言写的，原则上根本不可编程）和实现（比如允许用户自己给编译器补丁扩充语言且兼容性仍然可控； Rust 编译器插件的存在说明了设计者注意到了部分需求，但如 rustc::plugin 这种只关心 rustc 而不是 Rust 自身的流于实现细节的备胎解决方案仍然是不靠谱的），这脱离绝大多数现在的工业界语言既有设计的能力上限，因此被主流业界接受需要很久（可能到 Rust 自然嗝屁以后）。
所有之前在这个楼讨论的内容都不是这条路线。最近能看得到的绝大多数语言，包括 Rust 在内，甚至都不具备接近这条路线的创新。现在大概只有 Racket 这种预先强调 language-oriented programming 的做法和实现经验稍微能看一点，但 Racket 本身在技术上就有很多问题——例如从一个依赖 GC 的运行时剥离出来一个不依赖 GC 而具有显式所有权的核心语言，这基本除了回炉重造没有办法，而且 tooling 还是太弱了。
对应地，过于依赖传统的 AOT-central 的方案不可能是通用的实现方案——反省下 LLVM 这类的既有实现为什么连 libjit 都统一不了就能闻出点味道了。以 explicit SSA 作为核心 IR 的转换方案，使过程内和过程间优化的实现更加困难且难以自动化，迟早导致规模增加以后工程资源消耗的现实不可行（现在很多写编译器的赶鸭子上架已经超常发挥了，工作量规模一旦失控，加倍 996 也没用）。对应的前端实现也普遍比较粗放，很多都直接把什么 declaration 撸到框架内部，连翻译单元都没法做出和目标语言解耦的抽象，稍微跟 C-like 相差大点的就没法复用得整个重来，LLVM 撸成“库的集合”的好处很大程度被抵消了。
历史上比较能接近这里的长期目的的，大概只有 REFAL 这样的 metacompiling system，但这方面的研究几十年来一直相当初级，工业界接近这个目标的最先进的也就是 Graal/PyPy 这种类非典型的只能优化小部分类型开销的 partial evaluator ……所以可能得再等几十年业界才会认识到现在这条路走不通——不过这些都是超出主题的身后事了。

@ZiLong 倒也不是说凉……这方面一直有刚需，混不上饭吃是不可能的。不过除了政策市，和互联网的待遇差距不大可能填平，更像搞传统硬件的。
老实说，这个领域中的理论比较封闭所以习惯吃历史包袱的红利，并据这类和其它领域不通用的经验来成为护城河，所以外人觉得门槛高（确实高，但也就那么回事）。而 PL 这种底层的技术在这方面的演进和实践相对于 app 甚至 Web 前端都非常落后——理论 PL 界基本无关心，也没能力去设计整套解决方案，包括我上面提到的不够表达正交的 object identity 的问题（题外话，除去资源管理问题，所谓“面向对象语言”这里经常设计得比理论界整的更对路，但基本就没靠谱的经验，像 Singularity OS 什么的稍微有点气候的实验性项目也都停摆了）。这决定了 C/C++ 在排除历史包袱这个最大的特色（不论算是优势还是缺陷）之后，仍然有一定的底气赖在系统编程这个领域中，我也不得不承认再辣鸡确实也没法替代。
在有兴趣的情况下，选择 Julia 这类大概是比纠结系统编程更靠谱的（市场容量也未必就小）。因为 DSL 更注重业务领域的匹配，所以就算语言设计得烂，不良后果也没那么严重。这方面，最烂的不是个别语言自己的设计问题，而是不适合解决领域问题被强行用于业务领域导致的适配问题——所以退一步讲，这些语言的设计者只要有自知之明别觉得自己什么都能干而干成半吊子，光是挖 Python 之类的墙角就都不大容易饿死了，大有可为（

艹，WG14→WG21。

@MeteorCat 这里有个重要的本质差别：决定语言设计的所谓官方不对等。就社区支持而言，跟 Rust 官方相对的其实是 isocpp.org 而不是决定语言设计的 WG14，这里会有一定的脱节，需求不容易同步，所以 C++就有更容易跳票的成分，导致容易不靠谱更明显。反过来，Rust 的官方明显在一致性上是占便宜的。Rust 没有出 spec，核心团队文档和实现一窝端，所以面对需求变化的反应迅速，不过意味着大厂商支持就比较随缘；相对地，基本上 C++标准确定的东西都是有一定厂商支持的（只不过一直有很多阳奉阴违的矛盾），所以一出乱子就很难挽回了。这决定提供和系统支持相关的库会面临不同的阻力，所以 C++网络库难产的现象很正常。
但是，要让语言面向的业务范围更广，那就不可能通过单独的官方提供大而全的解决方案，因为资源有限不可能做到所有领域的最优化而一定会有人不满——特别是网络这块至少在所谓系统编程的领域中算是很高层而且需求不稳定的东西。更根本地，无论是面对碎片化的选型还是甩掉历史包袱都是业界的正常义务，一直都是“不爽不要玩”；用钦定唯一的方案暗示用户接口的（不见得靠谱的）稳定设计，而不是方便不同需求的用户进行不同的选择，随着用户规模的扩大会越来越难以妥协，根本上不是办法。
另外一个不同是我看 C++不爽的话可以 fork 个 C++自己用，但 Rust 没 spec 所以要连同实现一起 fork （虽然 C++已经麻烦到 fork 了起来也不大有意义就是了）。

@hehheh 00 到 10 年是参与的人少，所以看起来没进展，但整体提案质量比较高，实际有效的工作量比较大（当然，还是跳票了好几次，大多数进展都堆在 09~10 年了）。如果你跟进及时，那之后的体验相比起来是一点都不好，因为之前吹的最响亮的一些东西都没有及时交付，吊胃口出反效果了。而且看现在的提案，一些基础方向并没比十年前更清楚，瞎加的没验证过设计的乱七八糟的特性一坨（还有跟 C 密谋一起干翻现有 C++ 异常的……），以后可能更混乱，建议不要抱太大希望。

@hehheh RVO/NRVO 这类 copy elision 是直接优化没掉。
替换 copy ctor 为 move ctor 是 C++11 后的内容，因为 move ctor 是 C++11 引入的。
C++17 钦定一些情况下直接没有新创建的对象，这些情况下不再是可选的优化了。这算得上是 C++17 最大的核心语言特性上的变化。
C++11 到现在包括 draft 里加起来能实用（有靠谱实现）的内容都没有一个 C++11 的变动大，之后多少特性一样要么跳票几次要么回炉重造，你说比原来好……是想 peach。

@GeruzoniAnsasu Rust 是想替代 C++ ，但历史包袱决定它做不到。
它没有足够多的难以替代的项目、厂商支持甚至用户的支持，也没有足够具有超过现有语言整体设计的格局，所以没法保证避免和更新近的语言之间菜鸡互啄（虽然大致上是鸡头）。
难学倒是未必，至少不像 C++ 有那么多鬼哭狼嚎教你如何翻车的劣质教材。
这里还有个洞，就是 C++ 理论上应该能允许用户做好，但没有核心语言特性用户实际就做不好的情形——比如早就有 mojo 结果 C++11 还是把右值引用直接内建了。这是加新特性的动力之一，但之后加进去坑就坑大。（ C++ 为什么没有 destructive move ？因为类的子对象的构造怎么都不对头……）
Rust 历史包袱更少，就意味着在更 idiomatic 的用法和初期演化效率中都占有优势。C++ 用户基数大，历史包袱也大，加的特性越多就越作死，语言本身就越难以维护。并且现在 WG21 这方面的品味和水准就实在不咋地。凉拌吧。
难维护……看人了。某种意义上 Rust 的用户大致对应 C++ 用户的中间阶层——剩下的能用 C++ 写出可维护性不比 Rust 差的项目的用户以及被教残的 C++ 用户都不怎么会转进到 Rust，而没别的语言背景上手 Rust 是比较吃力的。

@TaAmSf C/C++ 在这里不占便宜。
用 C 的主要理由就是维护轮子，造轮子都嫌破事多。
用 C++ 的主要理由是维护轮子+造轮子。只是现在要用轮子的用户，基本连 C++ 也懒得用了，结果就是整个语言的发展都不会实质上朝能控制或进一步简化实质复杂性（而不是仅仅少写特定情况下的代码）的方向节制（即便 BS 成天嚷嚷 teachability ），而更在乎有能力造轮子的用户的需求。这样迟早一样会让没有能力造轮子的用户没事可做。

@sherlockgy @slanternsw 微软也就折腾 DSL 还行（不管是研究还是产品）。
MSR 搞 PL 的能出点名堂的都偏向现有问题上搬砖的具体实现而非整体设计，造越通用的语言越不顶用，也很难看出这些人有多重视这个方向。
看看那什么 Bosque 之流的水货都能带上微软的名号就知道这些人的态度了。

@ppphp 人类共识……就凭那一整坨连换行和 indent 都拎不清的蓝星猴子，你还是指望靠分布式共识发家致富比较有现实性……
方法论来讲，靠堆砌特性来设计语言是缺乏普适意义的错误方向，这点在几十年前 RnRS 的开头就说了（显然绝大多数语言在发展方向上这里就完全不合格）。然而现在 RnRS 自己都没太能搞定这个原则……
大部分有能力在这个方向上搞语言的，一开始就栽在用户不够就没用的调调上了，而要得到用户数量上的明显优势就必须妥协自己提供足够多特性，用户越多还越难拒绝，无法回头。这导致没有谁能实际上不违反不管是 PL 理论还是工程上的理想原则。
而更多的设计者根本就是完全没这个概念，只是先想出来让人用再说，到处一大抄，甚至毫不在乎被当作是外行（比如上面拿来婊的那个 Bosque ）。
除非能保证对拒绝共识的用户专政，这就没办法收场。这是价值观问题。

@noobma 这很大程度上不是 Rust 的问题，是本来就没法回避那么复杂的问题。
要回避复杂，代价是放弃准确的控制。比如，放弃显式所有权抽象，在大多数语言中实际上就是允许所有资源默认扔给 GC 管理这种特例，而没法表达更一般的情况。这个意义上，一部分问题来自用户自己，没想清楚问题自然就无法表达——大部分用只有显式释放或者有 GC 擦屁股的语言入门的用户都会习惯性地忽略这个问题：到底是谁保证你能使用资源？
想清楚了这点，之后会发现实践中能不失控的有效的套路也就那么几种。像 strong 和 weak，就算有 GC 擦屁股的语言也可能提供相应的特性，比如 java.lang.ref.WeakReference。
当然，严格说，Cell、RefCell 和 Box 的问题对没见识够多不同风格语言的用户来讲，是要复杂一点，这涉及到更普遍的语言设计策略问题。
具体一点，Cell 之类必要性和理解困难，同时来自于 Rust 想削减抽象复杂性的背景而忽略了对象可变性和对象的同一性(identity) 在更普遍的情况下正交的现实。
和这种设计对立的一个典型例子是 C++ ，它的不可变性(imutability) 由附加在一般不限制修改的对象上类型的 const 限定符来限制，这保证一般的可变和不可变对象总是简单对偶的（如果忽略 volatile 以及常量表达式之类的更麻烦的东西）。配合 C/C++ 的对象作为存储(memory) 的抽象，这很容易让只读和不只读访问的内存一一对应而容易理解。
而在 Rust 中，一般地，不存在可变和不可变存储的概念，而只有“共享只读”和“独占可读写”对象的对偶。这样的好处是简化了需同步并发的操作抽象且在许多情况下更实用，代码默认不那么罗嗦而稍微不容易出错（特别是默认不可变引用的范式能避免 C++ 新手到处丢 const 的问题），坏处就是破坏了正交性，特别是不保证单独分辨同一性的手段，而使语言难以扩展不同于简单二进制表示的可修改性来定义变化(mutate) 的不同操作。（虽然大多数用户现在日常用不到，主流编译器的 constant propagation 都还没法基于扩展可编程的不可变性来让类型系统进行推理，但这至少对语言未来的演化仍然有消极影响。）
Rust 用 Cell 和 RefCell 提供了 UnsafeCell 的安全变体。而 UnsafeCell 提供了“内部可变性”。后者在动机上相当于 C++ 的类数据成员上修饰的 mutable。在 C++ 的设计中，const 对象类型蕴含子对象类型也具有 const，这种类型系统的实现策略使 mutable 作用显得直白——无视类类型对象的 const 对子对象作用（ const 传播）这条类型系统默认规则。Rust 使用默认不可变而不是像 C++ 那样附加 const，这种内部不可变为什么必要在实现上就更加抽象而不容易理解（即使业务逻辑上“什么时候适合用”的理解难度应该是相同的）。
实际上 Rust 做得更多。为了确保安全，Rust 这里还可以具有运行时的类型检查。不过这在理解上就应该不是什么大问题了。
Box 在一定程度上也和避免表达同一性相关。这方面更典型的例子在一些传统上就不允许用户表达同一性的语言（粗略点说，就是和 ALGOL/C 相差得足够大的语言）上找到，可以参照 SRFI-111。

对了，看时间，这个应该是昨天了……

……好吧你这里的版本是拔网线，不过也已经够离谱了。