作者心声:这篇文章我写得可是小心翼翼,尽量避免任何过于肯定或者容易引起误解的表述。我也有自己的正常工作、没办法真正全身心投入到 Rust 的宣传工作,所以只能用这样一篇文章表达自己的感受。篇幅有限,文章内容肯定无法面面俱到,所以我把自己想到但没能讨论的部分都列在了文末。
Rust 过度炒作?不至于不至于
每当出现关于 Rust 的讨论,最终大抵都要以“炒作”问题结束。
很多朋友觉得 Rust 在网上水军太多,每天都会听到“Rust 最棒”、“人家 Rust 如何如何”、“Rust yyds”之类的言论。这帮家伙就不能消停一会?
确实,Rust 在网上热度很高,但大家还记得当初 Java 刚兴起时的情况吗?如果不记得,恐怕是因为各位还很年轻。
那时候市面上充斥着满是废话的商贸杂志,而且神奇的是,他们都爱报道计算机方面的内容。于是我们就会看到一系列关于 Java 语言、发展前景以及它能解决的问题等文章。
那时候的互联网还不像现在这样充斥着很多极端情绪和“复读”习惯,所以倒没有酝酿出激烈的争论,但人们的烦躁之情是共通的。
Java 语言那时候还没有得到实践检验,这种未经证实的技术报道太多了——没人用过、没人了解、没人在乎。毕竟虚拟机运行时之前就有,C 和 COBOL 也都非常成熟了,为什么非得拿 Java 来硬凑热点?
后来的故事大家都知道了,Java 不负众望、宰治了整个软件行业长达 20 年。接下来才是重点,咱们聊聊为什么没必要对“炒作”抱有过度恶意。
为什么总有炒作之声?
在 Rust 出现之前,我们没有必要反复强调某些问题,因为根本就没有真正的解决方案。每个人都知道缓冲区溢出是个大麻烦,而 Java 等语言可以解决问题;大家都清楚自主编写的数据结构缺陷多多,但 Python 等语言在这方面能出把力。
所以那时候的人们还不会以某一大类问题(例如「组合便捷性」和「内存安全性」)为切入点讨论痛点。毕竟既然不打算重新设计一种能解决问题的编程语言,谈得这么宽泛完全是在浪费时间。
唯一称得上共通难题的就只有安全性问题,但之前的解决思路要么是在性能与可维护性之间进行权衡(Python、Ruby、Erlang),要么就是维持在可接受的水平上然后弃之不理(Java、JavaScript、PHP)。
这些问题、甚至是整个问题类别,都成了程序领域中的“背景辐射”。每个人都知道有这些问题、每个人偶尔都会抱怨,但就是没有解决的办法。
直到 Rust 出现之后,大家才意识到,出现了一种能解决所有问题的技术,这意味着编程时代开始由问题与解决方案的多对多关系、真正走向多对一的统筹处理阶段。
于是我们在网上的讨论中逐渐开始从当前问题出发总结问题大类,甚至还要把解决思路拓宽到其他问题大类当中!这本应是个巨大的优势,但正是这种优势让 Rust 显得似乎一夜之间就无处不在,而且跟我们日常工作中的各个环节都息息相关。
“别再骗自己了”
作为技术人员和工程师的核心特征,大家应该很擅长冷静客观地评估系统。你可以先把“炒作”这码事放在一边,专门根据实际表现考量解决方案。决定判断的应该是事实、而非情绪,对吧?一旦因为“炒作”而抵制 Rust,那我们就离讨论的基本诉求越来越远了。更不用说极端的人身攻击了,那是小孩子打架般的玩意,不值一驳。
我之所以坚持认为“Rust 炒作论”是种有害的侮辱性言论,并不是因为我从 Rust 基金会那拿了钱,或者是想劝说大家购买 Rust Enterprise。
坦白地讲,我在编程行业待了 30 年,体会过用没有 type 安全设计的语言进行大规模重构,用会产生 GC 开销的语言编写快速服务,用缺乏良好内存清理机制的语言编写紧凑代码,再把这些成果运行在微型计算机以及后来的分布式多核心集群上。
这些我都干过,而且都成功了……但过程非常非常痛苦。所以当我看到 Rust 的一刹那,我就知道这是个好东西。
我之所以力推 Rust,是因为它真的很出色、没准能帮助大家解决现实问题(包括很多你已经觉得无药可救的问题)。这篇文章完全发自肺腑、出于真诚,我只谈自己的切身感受与判断;如果大家有不同意见,也请以同样真诚的态度给出说明,感谢各位。
别搞“网络纠察队”
更重要的是,别搞什么“网络纠察队”。所谓针对 Rust“水军”和“炒作”的抱怨其实就是一种网络纠察行为,或者说是对人们的立场乃至表达方式做出的另一种抱怨。相信很多朋友也和我一样,已经厌倦了这种毫无意义、既无成效也无建设性的反复争论。
我写这篇文章,是因为我自己有表达的冲动。各位觉得不喜欢可以自行离开,这很正常。但我绝对不会刻意去迎合某些人脆弱的神经,也不想顺应那些在网上喷 Rust 喷到血压上升的家伙的立场。
我的出发点非常单纯:只要是能给编程行业带来实质性改善的好东西、只要是能让程序员日常工作更轻松的东西,我就支持。
别在抱怨中错失良机
曾几何时,Java 也卷起过一股“风潮”。但随着“炒作”的消退,这种争议也随之瓦解。
总有人说“真正的”程序员绝不用 Java,我觉得 Rust 倒是没有这个问题,因为它“够难”(但其实并不难,至少没大家想象的那么难)。
之所以没人把 Java 视为威胁,是因为当时互联网行业正在快速发展,众多新岗位的涌现让新语言成为单纯的工具而非威胁。当时最大的分歧,就是很多人觉得 Java 难度低,“格局”不够,用了它好像就跟普罗大众距离拉近了一般,无法凸显自己编程精英的高中地位。
但如今不同了,经济形势放缓,软件开发行业也受到了波及,每个人都需要谨小慎微地规划未来的前进道路。与其靠自己的脑袋记住一切陷阱,为什么不直接使用一种能消除这些陷阱的语言?谁把精力节约下来用在更有意义的地方,谁就能在残酷的市场竞争中占据主动。
从企业的角度来看更是如何,Rust 能帮助大家省下代码调试或重构方面的成本,规避安全演习开支,并通过近裸机运行方式省下硬件投入。
我现在的 Rust 编程速度已经不亚于 Python 了,相信大家也能做到。软件的上市时间非常重要,而 Rust 与脚本语言之间的开发效率差距正在迅速缩小。如果继续顽抗到底,那你的解决方案发布速度会变慢、启动及维护的成本会更高,其他人就可能在你继续抱怨的同时悄悄瓜分掉你的市场份额。
正因为 Rust 具有显著的竞争优势、能够编写出超越其他语言的高质量代码,所以招聘经理们才开始用 Rust 水平衡量顶尖人才的业务能力。在不久的未来,这种标准将成为新的常态,哪怕每天把 Rust 喷上一万遍也改变不了这个现实。
写在最后……
我知道,很多朋友会在评论区里纠正文章里的某些细节,这里我就自己列出来算了:
大获成功的 Java 其实黑点也不少,一样充满了问题。
一切得慢慢来,操之过急只会把编程员工们吓跑。
上世纪六十年代就有人提出过分类解决问题的想法,但无一例外都失败了。
也许我这 30 年里写过的代码都很差劲,确实有这种可能。
水平够高的程序员当然可以克服或规避其他语言中的固有缺陷。
语言不是万能的,任何语言都有可能写出糟糕的代码,还是要看人。
语言不是万能的,任何语言都有可能写出不安全的代码。
我针对的不是各位读者,只是一种现象。对事不对人。
Rust 当然解决不了所有问题,这一点必须实事求是。
除开 Rust,我也见过其他不少优秀的技术方案。
Rust 是门大语言,涉及的学习内容众多,所以上手难度确实不低。
很难把 Rust 的改进效果量化出来。
Rust 中也有很多目前无法、甚至永远无法解决的难点和问题。
能用好垃圾技术确实算是种特长,只是这特长没什么成长空间。
如果能用好垃圾技术真有成长空间,就意味着市面上必须不断涌现更多垃圾技术……也许会,可我觉得但愿不会。
可能 Rust 也是垃圾技术之一,只是我还没意识到。
我说自己的 Rust 编程速度跟 Python 开发相当,这可能是因为我的 Python 编程速度本就不咋的。
毕竟还有自己的工作,所以非常抱歉,我只能在文章中做出概括性的论述,没法结合具体问题详尽介绍 Rust 的使用心得。
这篇文章本身也属于抱怨,我承认~
原文链接:
评论 1 条评论