FrankHB

@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。

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

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

@nyanyh 能配备那么睿智的运营的作坊，你要是作为负责人，敢指望程序员能顶住压力短时间正确地分析出结果然后再调整吗？能一而再再而三地用拔电源的方式创造运营事故，再继续回档增加工作量不是作死？整个项目本来就已经凉了一半，如果因此凉完了怎么向资方交代？
听说后来是先补偿再表态追查不当得利，这个措施没那么明显的智力问题，姑且还有看一步走一步的余地。

@youxiachai 你要往编译原理上靠那也是野鸡知识。
这个（最表面上层次上的）问题说穿了很简单：形式参数作为绑定变量的名称，它对语言的语义无关紧要，正经的语言设计一开始就没有把它设计为可以让用户可靠地进行依赖的接口特性，而只是实现细节。
更进一步的原理是，支持反射形式参数名破坏 alpha renaming 保证的语义等价性——保证重写规则中仅仅替换形式参数名，只要不冲突，就能保持语言的语义不变。
这背后的原则是变量名的含义应对确定如何计算的语义规则不透明，语言设计原则上不需要干涉用户怎么命名变量，这样用户可以按需自己选择命名约定以满足不同的需求。（这也是一票重构工具的基础。）
这在工程上给语言的设计者也带来了很大的方便——至少不需要就自然语言的含义纠结了，也不需要非得把命名规则这样零碎的东西写到语言的规格描述里才能用，就算写进去了也原则上不需要和改动语言特性冲突。
（至于某些 PL 强迫用户使用 camelCase 之类的瓦釜雷鸣，说白了这来自特定自然语言内部的缺陷，跟 PL 的设计原则上本应无关——比如要是一开始用中文就连纠结 case 的基础都没有了——虽然中文有另外的破事。如何纵容自然语言的旮旯污染到 PL 设计上这就是另一回事了。）
所以正经的语言不管编译不编译，都不会去支持这样的特性。方便编译优化，是另一个顺带的副作用罢了。
当然，不是所有的简单明显语义等价性都该教条主义地被保留，例如破坏 eta equivalence 允许函数调用带有可观察的副作用，很大程度上是可取的。但是破坏 alpha renaming 并没什么这样显然的好处还会添乱，得不偿失。
但造成 LZ 问题的不只是不理解为什么语言需要这样设计。更深层次的问题是，为什么需要反射来提取这样的信息？
说白了也不复杂——语言没提供足够的机制（例如通用的 AST 接口）让用户自然地以一致的方式选取如何保留源代码中的信息，以至于表面看起来不复杂的需求突然就土法炼钢了。
也不是特地需要婊 Java （几乎所有静态语言都有类似的毛病），但 Java 这种典型钦定编译 phase 没 homoiconicity 翻译时元编程又叒鸡的静态语言，就是这种先天不足的典型。所以没特地适应如何避免这种缺陷的用户遇到这类问题，以及一般的解决方案只能绥靖，就见怪不怪了。

挂 BOINC。
不过，像我用 SB2 之类的……
……算了，房间里多放台机器开 BOINC、、、