我们常在各类介绍Rust的文章中看到“Rust是JS的未来”这样的话，那么我们是不是应该现在就开始学习它？
最受欢迎的编程语言？
前两天我们团队的同事在聊算法考试，进而讨论哪个是最好的语言，有说是Java的，有说JS的，有说Swift的，还有说这个话题中的“梗王”——PHP的，当然，也还有说最好的语言当然是普通话的~这个话题就是这样，一千个读者心中，有一千个哈姆雷特。不过，要问参与StackOverFlow调查的开发者，哪个是最受欢迎的语言，你会发现一个惊人的事实，在2016-2021年，这项调查的冠军分别是——
没错，就是Rust，Rust，Rust，Rust，Rust和Rust！刚好我也是从今年年初开始了解Rust，想结合这段时间的学习聊聊我对它的认识。
Rust为什么这么受欢迎？
如果说之前各类的编程语言是葫芦兄弟，各有所长又各有所限的话，那Rust就是融合了葫芦兄弟们的全部优点的葫芦小金刚了。Rust诞生自Mozilla员工Graydon Hoare，而Hoare自称为职业编程语言工程师，换言之，他是专门研究编程语言应该是什么样的人。比如你会发现Rust中很多类似解构、字符串format的写法很像TypeScript，定义方法中使用到的self、字符串切片很像Python，引用，取地址符，解引用等让你想到C++、结构体会让你想到C，另外还有借鉴自Haskell的函数式等等，这样融合的结果就是：Rust可以兼顾内存安全和线程安全，做到安全、并发和高效。它不需要专门的运行时环境，运行时需要占用的内存在编译期间就能确定；而且它没有垃圾回收机制，通过其独特的内存安全管理实现，因此Rust几乎是运行效率最高的语言；在获得堪比C/C++的运行效率的同事，还避免了悬空指针、内存安全等问题。用牛顿的话总结就是：“如果说Rust看得更远一点的话，那是因为它站在了巨人们的肩膀上”。
Rust能做什么？
JavaScript生态的繁荣，始自这样一句话
Any application that can be written in JavaScript, will eventually be written in JavaScript. （任何可以用JS来编写的应用，最终都将用JS来编写）
这句由Atwood’s Law在2007年提出的“口号”也被称作Atwood定律，这些年我们看到了这个定律在被广泛印证：我们可以用JS来做各种事情，比如写网页、写APP、写小程序、写后端、写基建工具。这句话也说明了另一个现象：现在很多涉及JS的问题，都是JS开发者在使用JS解决。然而，如果在任何场景下都要通过JS去解决问题，是不是也会有些“矫枉过正”呢，比如说我们常提到Node.js可以让JS写后端，它的模块可以实现与系统API的交互，但Node.js其实并不擅长处理CPU密集型任务，那么，我们是不是一定要用JS去解决类似这些本来不适合用JS处理的任务呢？ 当然不是的，比如Vite，就是通过esbuild实现了超快的构建工具，而esbuild是用Go语言开发的，效率甚至可以提升至原来的至多70倍
同样的事情也出现在Deno、Next.js 12上，你会发现，天下人苦Webpack久已，越来越多JS的基建工具可能会使用Rust/Go等这类兼具开发效率和运行效率的编译型语言去解决，因此，会有越来越多的人因为SWC而去了解Rust、或者因为esbuild而去了解Go。比如志在取代Prettier的Rome ，就在用Rust重写。还有知名软件1Password、Dropbox的后端，巨头公司谷歌、微软、亚马逊、苹果、华为，均有部分模块、平台使用了Rust在重写。由此可见，未来Rust一定会在更多领域占据举足轻重的位置，除了基建工具，比如Node.js开发同学需要C++来实现部分扩展时，也可以用Rust替代完成。
Rust有什么缺点吗？
Rust既然这么厉害，要立刻开始学习它吗？
当然可以。不过，我觉得也可以等等再说。
首先，因为如果你日常工作是通过JS写前（React/Vue等）、后端（使用Egg.js/Nest.js/GraphQL等）业务，学习Rust并不能迅速使用在你的工作中；
其次，前不久Rust刚刚发布了其 2024路线图（它这个路线图每三年发布一次，从2015年Rust1.0 发布后，2015->2018->2021->2024）, 其中，拉平学习曲线就是其中一项重点工作，大家都说Rust学起来太难了，所以我觉得可以等等看官方是否会通过更多的语法糖和其他方式减低学习难度；
最后也是最重要的原因，学习Rust真的很难！上面既然说到Rust都把拉平学习曲线提上日程了，那么Rust现在的学习曲线是怎么样的呢？有人说是这样的：
而如果你是习惯了JS的灵活再来接触这门重编译轻运行的语言，可能真的很容易被劝退，比如上图中的cannot borrow immutable borrowed content '*v' as mutable, 毫不夸张的说，你想见到它实在太容易了。
Rust的难让我想到了Angular，为复杂项目而生，2015-2016年就支持了TypeScript，API大量使用Rx封装，这么好的框架，在国内居然没什么热度，其实就是因为——难，进而造成生态差，热度低，走向更差的负向循环。
因此我觉得，如果你觉得Rust可能有点意思，完全可以多花点时间和精力去了解一下；反之你如果觉得现在还早，也可以等等看它的那些“榴莲味的语法糖”会不会在后面的版本变得甜一点再去学习它。
最后说说从我自己学习Rust的感受，Rust给我带来了什么呢？
没有挽过的船新版本
写代码，很多时候就是在管理内存。以我们创建一个动态数组为例（Java中的ArrayList），创建时就有一个引用指向它，当这个数组被传入一个方法时，就有多了一个引用指向它，以此类推，当不确定有多少引用指向它时，它占用的内存就无法释放，当同样的内存无法释放的问题成百万倍上千万倍出现时，就会造成OOM。
因此C、C++等语言会要求开发者手动处理该问题，当然，这是十分不便的；
Java、Node.js开发中，无需开发者费心，会不定时的进行垃圾回收，但GC过程中会Stop the world（可以理解为安卓手机偶尔的卡顿感），这种体验并不好；Objective-C/Swift通过ARC（自动引用计数）来判断是否需要释放内存，同样它也有性能消耗。
这可能也是Java面试中为什么总是逃不过垃圾回收算法类问题的原因，因为如果你对Java中的GC算法了如指掌，Node.js的垃圾回收知识你也就手到擒来了。不过还有没有另一种全新的体验？
有，就是Rust，他通过所有权机制，相当于和Rust的使用者“约法三章”，无需GC就可以保证内存安全，且当程序运行时，所有权特性不会减慢程序运行的速度，不会出现STW(Stop The World）。
另外，Rust重编译，轻运行的理念其实体现了“类型系统中正确性、完备性和可停机的不可能三角”，就如分布式系统中的CAP的不可能三角一样，每种系统、算法可能都是“鱼与熊掌不可兼得”，没有银弹，根据实际场景使用合适的数据结构、算法才是永恒的主题。而当合理的取舍在特定场景取得成功，可能就是全新的体验——比如非阻塞之于阻塞，LRU之于HashMap、LinkedList的使用，亦或者React从15到18的或大或小的幅度的改变，只为带给大家的异步可中断、可调度、有优先级的更新等等。
成长路上的良师益友
以上面说到的内存管理问题为例，Rust的解决思路是：共享不可变，可变不共享。如果一个值只能被一个变量所引用，保证其有单一的所有权，不就避免了上面的问题。还是以上面的动态数组为例，假如你在主流程中创建的一个动态数组，被传入某个方法时，它的所有权就“换到了”新的引用上，旧的引用就可以丢弃了。
因此Rust和开发者的约法三章如下：
- 一个值只能被一个变量所拥有，这个变量被称为所有者;
- 一个值同一时刻只能有一个所有者;
- 当所有者离开作用域，其拥有的值被丢弃;
当然，这是针对放在堆上的数据，按这个逻辑来，放在栈上的数据管理起来则轻松许多，因此几乎每个Rust初哥在理解所有权之前，都对创建一个类型的变量时是采用栈内存还是堆内存要思考良久，这可能就是编写Rust代码中对开发者的启迪会增加很多的原因，也是cannot borrow immutable borrowed content '*v' as mutable比比皆是的原因。不过得益于Rust及其详尽的错误提示，把它看成夯实基础和成长中的良师益友也并不为过。
小悟空的超圣水
当然，Rust也非能解决所有问题，虽然有人都说Rust代码只要编译不出错，甚至可以直接上生产环境，不过它也有防不住的bug。我们应该如何看待Rust？
我是觉得可以把Rust看成《龙珠》中的超圣水，小悟空在遇到无法战胜的强敌时，以为喝了超圣水就能实力大增进而击溃强敌，可实际上他喝到超圣水时才知道，使他实力大增的并不是超圣水，而是他和加林仙人争抢超圣水的过程。同样，通过学习Rust，可以促进你做更多思考，实践来夯实基础，提升对各类问题的理解。
希望对Rust和成长感兴趣的朋友们，可以早点喝到Rust超圣水。
最后分享一些学习资料：
Rust中文文档大全：rustwiki.org/
rust playground(类似codepen，不过链接里这个程序有问题，可以通过这个看下Rust丰富的提示)：play.rust-lang.org/?version=st…
本文参考资料：【骇客说】Rust，JavaScript 的未来？
打个广告： 之前有同学说过，想听一些关于低代码平台的分享，刚好，这周末就有，欢迎关注本周六——5月28日下午14点掘金公开课的直播，我们团队的莫大师会为大家带来他对
低代码总结成两篇专利那么多的独到见解，欢迎大家届时一起参与直播，交流探讨~
