正文
所谓种瓜得瓜种豆得豆，语言诞生初期的世界观，决定了语言之后的走向。很多人抱怨 golang 没有泛型，但泛型恰恰和 C-like 这个思想是冲突的，因而如果要引入泛型， golang 势必需要对其世界观进行妥协，这种妥协带来的代价将会是巨大的（起码会急剧影响 golang 语言的简单性，以及其引以自豪的编译速度）。
对于 Rust 而言，它诞生的初衷是作为一门可以替代 C++ 的系统级语言，满足如下核心价值观[3]：
显然，Memory safety 和 productivity 是 C++ 开发者的痛点。一门新的系统级语言可以在不失其效率的情况下达到内存安全么？C++ 做了很多探索，创造了不少智能指针，把 RAII（Resource Acquisition Is Initialization）引入语言当中，但由于历史的包袱，使得 C++ 只能在现有的体系下修补，无法从根上解决这一问题。Rust 则不然，它站在 C++ 的肩膀上，引入了所有权（ownership）和借用机制来提供内存安全，并创造性地使用了类型安全来辅助并发安全。所有权和借用机制虽然优雅且很容易理解，但它和我们所熟知的编程范式大为不同，让程序员无法随心所欲写出错误的代码，再加上 Rust 有意地在编译时就把这些错误暴露给开发者，使得 Rust 初期的学习曲线变得非常陡峭，对那些学了个一知半解就喜欢上手的开发者来说，尤其陡峭。
也因为 Rust 对自己系统级语言的定位，使得它对性能有一种偏执 —— 语言提供给开发者的抽象需要尽可能达到零成本（Zero-cost abstraction）：任何功能只要你不用，就没有成本；你如果使用，你自己手工优化的代码也不可能比语言为你生成的代码效率更高。因为这种偏执，使得 Rust 即便早期对异步 IO 有 green thread 这样在其他语言看来已经是相当不错的支持，在 Rust 进入 1.0 版本时，这个功能还是被彻底拿掉[3]，因为它会像 golang 一样，即便开发者不使用任何 green thread，其运行时带来的额外开销还在那里。所以 Rust 对异步 IO 的支持，直到 1.0 发布数年后的 Rust 1.39 async/await 正式 stable，才重新完美具备。既然提到了 async/await，容我再多说一句，我认为 Rust 在 async/await 的零成本抽象上带给整个编程语言世界的影响是巨大而长远的，它就像那个打破了「四分钟一英里」魔咒的 Roger Banister [4]，让世界知道：高级的抽象并不必然以牺牲性能或者添加额外的运行时为代价。
Rust 还有一个重要的，被大家低估的世界观：公开透明（explicitness）。使用者可以对他所写的代码做到完全了解和掌控。
很多「高级」编程语言会营造一种易于学习的氛围：你不需要了解一切，不需要熟悉计算机工作原理，不需要掌握操作系统的基本知识，你也可以「高效」编程。这其实是一种假象。如果你做的事情仅仅和 CRUD 相关，那么掌握一些高层次的 API 的确可以很好地完成工作，但当你面临更复杂的系统设计时，当你想成为一名
有追求
的开发者时，你会遭遇瓶颈 —— 你还是得老老实实构建需要的知识体系，可是当初的「轻松」已经成为负担，就像练习钢琴一开始在双手的姿势上走了捷径，随着联系难度的增高，这捷径会反噬你。
而且这种假象还会被人才市场无情戳破。Java 工程师的确不需要了解内存的运作机制也能编程，但面试的时候，GC 的原理，Java memory leak 可能产生的原因，Java VM 是如何工作的这类问题还是屡见不鲜。原因无他，你如果不了解一切，你无法写出高效安全且设计良好的代码。同样是程序员，在并非供不应求的大环境下，用人单位更青睐那些有追求的程序员。
Rust 没有试图遮掩，它将所有你需要了解的细节明确地在编译环节暴露出来，并且把什么可为什么不可为的边界清晰地展现。这的确会给开发者带来学习的负担 —— 如果一个开发者对一门语言的从小工到大牛的掌握过程中所经受的
全部痛苦
是 100 分的话，Rust 的公开透明 —— 编译器把丑话说在前面 —— 帮你把 100 分降低为 90 分，然后在头 6 个月让你经受 70 分痛苦，接下来的 5-8 年经受剩下 20 分的痛苦；而其它语言会让你在头一两年只经受 20-30 分的痛苦，哄着你，呵护着你，然后在接下来的 5-8 年让你慢慢经受之后的 70-80 分的痛苦。
