Rust口碑那么好,为何学的人那么少?
放眼编程语言界,新旧势力的交替历来暗潮涌动又动人心弦。而在最近两年,Rust的表现不可谓不抢眼。
根据SlashData 2021年开发者报告显示,使用Rust编程的开发人员在过去24个月内增长了两倍,达到了220万。过去C/C++、Java等是大厂的常用语言,而如今,字节跳动、亚马逊、谷歌、苹果均已经用上了Rust语言,这意味着学好Rust语言就有机会找到高薪工作。
不过,也有人认为Rust学习门槛高,戏言“Rust的语法有点反人类”。那么事实到底如何呢?
Rust最初由Mozilla员工Graydon Hoare在2006年设计和发布,目前由Mozilla团队和一众开源社区成员共同开发和维护。
Rust能火,并非偶然。Graydon Hoare曾形容:“Rust是一种采用过去的知识解决将来的问题的技术。”站在前人的肩膀上,Rust很大程度上解决了很多其他编程语言的痛点。
首先,Rust发挥了静态语言的优势。相较动态语言在调试和运行时的不确定性,静态类型的语言允许对数据及其行为预先进行编译器级别的检查和约束,在运行时只保留少量的类型检查,这极大地避免了程序员的麻烦,同时有益于鼓励长期的可维护性。
其次,Rust解决了并发条件下的数据竞争问题,让并发更容易。当两个线程同时访问同一内存时会发生数据竞争,这就可能导致某些不可预测的行为。Rust从编译阶段就将数据竞争解决在了萌芽状态,保障了线程安全。用户可以用库的形式实现各种高效且安全的并发编程模型,进而充分利用多核时代的硬件性能。
再者,Rust做到了更好的内存安全特性。在内存管理上,常见的方式有两种:要么如Java、Python一样使用垃圾回收算法,要么像C++一样手工管理内存。但垃圾自动回收必然影响性能,手工管理内存则可能会出现内存泄漏和悬停指针之类的问题。Rust不同,其所有权系统在编译时就分析程序的内存管理,而且没有额外的运行时开销。这种无垃圾回收器的内存安全机制是Rust经典且核心的设计之一。
还有,作为系统级编程语言,Rust的基本理念是 “零成本抽象”。这一理念让Rust具备高级语言表达能力的同时,又不会带来性能损耗。与其他系统级编程语言(如C或C ++)相比,Rust不需要程序员将所有时间都花在细节上,而是通过添加更高层次的编程概念,确保使用的抽象几乎没有运行时开销,这种抽象与等效的手写代码具有同等的性能。
总的来说,在性能上,Rust内存利用率极高,能够胜任对性能要求特别高的服务;在安全性上,Rust丰富的类型系统和所有权模型保证了内存安全和线程安全,在编译期就能够有效阻断各种错误的产生。
有着如此表现的Rust虽然还是编程语言界的“小鲜肉”,却迅速收获了开发者们的青睐。根据Stack Overflow 2021年开发者调查报告,Rust连续六年成为最受开发者喜爱的编程语言。
不过,“最受喜爱”并不等于“最想使用”。
尽管口碑好、人气高,但Rust的学习成本高几乎是众所周知的。在官方的多次调查中,不少开发者提到需要降低学习门槛,让Rust更容易被学习。2021年Rust Survey调查中,有47.41%的受访者认为采用Rust很有挑战性,仅有17.14%认为挑战性不大。
可以说,除了部分具备一定的C/C++经验的开发者在使用Rust时会容易一点,很多人会因为“太难上手”而对Rust望而生畏。
Rust到底值不值得花功夫去上手?我们可以从它与其他语言的比较中一窥端倪。
Rust常常被认为是C++的竞争语言,但这种说法也会被一些C++拥护者吐槽为“碰瓷”。不可否认,Rust很受欢迎,且颇有后劲,但目前来说,C++的主导地位依旧不可动摇。宏观来看,C++拥有更大的社区、更广泛的用例,并且在实战中得到了绝大多数企业的认可。但另一方面,Rust在安全性上表现更优,没有C++那么重的历史包袱,作为新生力量潜力更大,等生态更加丰富后可能会更有作为。
内存安全:同为系统级编程语言,C++为了保持速度,没有走内置垃圾回收机制的路子,将内存安全问题留给了开发人员。而Rust通过其所有权系统全面强制并提高了其内存安全性,基本消除了手动内存管理的需要。
智能指针:Rust和C++语言都广泛支持指针,在两种语言中,首选都是智能指针。Rust标准库提供了几种与C++类似的智能指针,如Box 框架和库:Rust和C++都有大量的框架和库可以使用。尽管发展时长差距较大,但Rust目前已经有大量库可供网页开发、游戏开发、区块链等使用。而 C++库主要是标准库,是类和函数的集合。两种语言都有大量活跃的贡献者。
包管理和工具:Rust的官方包管理器是Cargo,就普遍反馈来说比较好用、很有竞争力。而C++在包管理方面也有Conan之类的工具,发展也不错。两者使用体验如何见仁见智。
并发性:两种语言在并发中表现均很稳健。但在线程安全方面,面对数据竞争这种难以定位的并发漏洞类型,Rust的内存安全特性更有助于预防这类问题的发生。不过,对自身代码非常自信的程序员可能会觉得,Rust在实现多线程应用时过于束缚。
社区支持:C++有C++标准委员会的领导,而Rust也有Rust基金会的支持。两种语言的社区都很活跃。不过因为C++发展时间要长得多,生态上肯定要比Rust成熟很多,受众基础也要大得多。
归根结底,所有语言都是工具,真正使用时都要因地制宜。作为一门优缺点都极为鲜明的语言,Rust在实战中表现如何仍需要开发者的亲手验证。有位C++程序员的评价或许可以给我们更多启发:
“虽然Rust定位于一门系统级编程语言,但它并没走C++兼容C的老路,完全没有历史的包袱,可以轻装上阵,充分吸收各家编程语言之长,避其之短。Rust有完全不亚于C++的表达能力和性能,又解决了C++的最大痛点(内存安全、线程安全),这对C++程序员来讲无疑是非常有吸引力的。目前,C++仍然是我的主力编程语言,但我对Rust是看好的。它不仅实用,反过来也会促进对C++中关键概念和问题的理解。”
在代码江湖,编程语言总是呈现出“江山代有才人出”的态势。Rust作为一门年轻的语言,面向一众老前辈,也展示出了作为后起之秀的锐气和野心。
在今年上半年, Rust语言设计团队(Lang Team)在官方博客中公布了Rust语言2024年的更新路线图。这张路线图昭示了Rust语言的未来发展方向。其重点有三:
一是努力拉平陡峭的学习曲线。面向Rust学习门槛高的问题,Lang Team力图通过各种手段简化程序,使开发者能更轻松地表达代码意图,而不需要处理逻辑实现的各种细枝末节。
二是让Rust库的生态系统更加轻松协调。Lang Team希望通过帮助管理功能生命周期,扩展库的功能,以及增强互操作性,使库的作者能够更好地服务于他们的用户。
三是进一步扩大Rust项目规模。为更有效地推进Rust发展,Lang Team希望让开发者能对团队的现存问题、工作状况一目了然,并对他们可以如何提供帮助更加清晰,使开发人员能够积极参与推动他们热衷的工作。
不过,对于Rust的前景,依旧众说纷纭。
有人说,Rust可能还是干不过老语言,终究难逃昙花一现的命运;
也有人说,Rust可能在Web应用开发、嵌入式设备开发等领域另辟洞天、大有作为;
还有人说,Rust也许会吞下C++大部分应用场景,在漫长的发展期后完成登顶……
而对于程序员是否要学Rust,支持和反对阵营也同样各执己见。
支持者给出的理由,主要集中在以下几点:
Rust站在巨人的肩膀上,也确实解决了C++的部分问题,很好地平衡了性能和开发效率。
一些企业,尤其是大型公司,已经在使用Rust或正计划使用Rust。以后对于Rust开发者的需求会持续上升,而且可以预见薪酬很可观。
作为一门年轻的语言,Rust的领域还没那么卷。抓住这个时机就有望成为这片“新大陆”的掘金者。
反对者则认为:
从职业发展考虑,对萌新来说,学习Rust得不偿失。因为Rust目前还是一门小众语言,将来会发展成什么样均未可知。而其他更为成熟的语言,掌握之后在实践中已经可以满足大部分业务需求。
Rust的学习门槛决定了,有能力钻研其语法的程序员,用别的语言也很少会犯Rust想要从根源上杜绝的"低级错误";而对于基础薄弱、编程思维混乱的程序员,很少能学进去Rust。这个矛盾就让Rust有点“不上不下”。
程序真正面向的是人,而不是机器。语法简单、易于理解、减少程序员的心智负担才应该是编程语言未来的发展方向。Rust显然不符合这一点。
回顾这些论点,可以发现,其实作为局中人,要预判一门语言的发展是很难的,因为没有人可以窥见其发展全貌。而且每门语言的发展也需遵循其自身的生命周期,不同阶段的评判标准不同,结论自然也不一样。或许就像有人说的,“我不讨厌任何编程语言,我只是讨厌还没掌握的语言。”具体到每一个开发者,所有的争论、质疑、好恶都要在尝试、学习、实操中逐步地变化演进。
参考资料:
https://zhuanlan.zhihu.com/p/342849423
https://blog.csdn.net/oSuiYing12/article/details/106844271
https://www.toutiao.com/article/7083687609608339998/
https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html
https://thestack.technology/rust-language-explosive-growth-challenges-rust-governance/
来源:51CTO技术栈
本页共115段,4620个字符,11071 Byte(字节) Google Launches Carbon, an Experimental Replacement for C++ 谷歌推出Carbon,C++的实验替代品Carbon Frustrated by the slow evolution of the C++, Google engineers have launched a new “experimental” open source programming language, called Carbon, as a possible successor to the venerable but aging C++. 由于对C++的缓慢发展感到失望,谷歌工程师推出了一种新的“实验性”开源编程语言,称为Carbon,作为古老但老化的C++的可能继任者。 Just as Microsoft built Typescript to update JavaScript, and Kotlin was created to shore up weaknesses in Java, Carbon could serve as a successor language to C++, one that offers an easy jumping off point for developers to a newer language that addresses modern development concepts such as memory safety and generics. 正如微软构建Typescript来更新JavaScript,创建Kotlin是为了弥补Java的不足,Carbon可以作为C++的后续语言,为开发人员提供一个轻松的起点,以开发一种新的语言,解决内存安全和泛型等现代开发概念。 Google engineer Chandler Carruth introduced the language this week at the CPP North C++ conference in Toronto. 谷歌工程师钱德勒·卡拉斯本周在多伦多举行的CPP North C++会议上介绍了该语言。 Wither C++ 凋零的C++ Long the language of choice for building performance-critical applications, C++ is plagued with a number of issues that hamper modern developers, Carruth explained on a GitHub page. It has accumulated decades of technical debt, bringing with it many of the outdated practices that were part of the language’s predecessor, C. The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux and its package management ecosystem, Carruth charged. Carruth在GitHub的一个页面上解释说,C++长期以来一直是构建性能关键型应用程序的首选语言,但它面临着许多阻碍现代开发人员的问题。它积累了数十年的技术债务,带来了许多过时的做法,这些做法是该语言的前身C的一部分。Carruth指出,C++的守护者优先考虑向后兼容性,以便继续支持广泛使用的项目,如Linux及其包管理生态系统。 The language’s evolution is also stymied by a bureaucratic committee process, oriented around standardization rather than design. Which can make it difficult to add new features. C++ has largely a sequestered development process, in which a select committee makes the important decisions, in a waterfall process that can take years. 该语言的演变也受到官僚委员会流程的阻碍,该流程以标准化而非设计为导向。这会使添加新功能变得困难。C++在很大程度上是一个封闭的开发过程,在这个过程中,一个专门委员会会做出重要的决定,这是一个瀑布式的过程,可能需要几年的时间。 “The committee structure is designed to ensure representation of nations and companies, rather than building an inclusive and welcoming team and community of experts and people actively contributing to the language,” Carruth wrote. “Access to the committee and standard is restricted and expensive, attendance is necessary to have a voice, and decisions are made by live votes of those present.” “委员会的结构是为了确保国家和公司的代表性,而不是建立一个包容和欢迎的团队和专家社区,以及积极为该语言做出贡献的人,”Carruth写道。“进入委员会和标准委员会的机会受到限制,费用昂贵,出席会议必须有发言权,决定由出席者现场投票作出。” Carruth wants to build Carbon by a more open community-led environment. The project will be maintained on GitHub, and discussed on Discord. 卡鲁斯希望通过一个更开放的社区主导的环境来建设Carbon排放。该项目将在GitHub上维护,并在Discord上讨论。 While Carbon began as a Google internal project, the development team ultimately wants to reduce contributions from Google, or any other single company, to less than 50% by the end of the year. They ultimately want to hand the project off to an independent software foundation, where its development will be led by volunteers. 虽然Carbon最初是谷歌内部项目,但开发团队最终希望在今年年底之前将谷歌或任何其他单一公司的贡献减少到50%以下。他们最终希望将该项目移交给一个独立的软件基金会,由志愿者领导其开发。 What’s in the Box? 盒子里有什么? The design wants to release a core working version (“0.1”) by the end of the year. Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need to check and recheck the code for each instantiation. 该设计希望在年底前发布一个核心工作版本(“0.1”)。Carbon将建立在现代编程原则的基础上,包括泛型系统,这将消除对每个实例化的代码进行检查和重新检查的需要。 Another much needed feature lacking in C++ is memory safety. Memory access bugs are one of the largest culprits of security exploits. Carbon designers will look for ways to better track uninitialized states, design APIs and idioms that support dynamic bounds checks, and build a comprehensive default debug build mode. Over time, the designers plan to build a safe Carbon subset. C++中另一个急需的功能是内存安全。内存访问错误是安全漏洞攻击的最大元凶之一。Carbon设计者将寻找更好地跟踪未初始化状态的方法,设计支持动态边界检查的API和习惯用法,并构建全面的默认调试构建模式。随着时间的推移,设计师们计划建造一个安全的Carbon子集。 According to the documentation, the language will support: 根据文件,该语言将支持: Performance-critical software 性能关键型软件 Software and language evolution 软件和语言进化 Code that is easy to read, understand, and write 易于阅读、理解和编写的代码 Practical safety and testing mechanisms 实用安全和测试机制 Fast and scalable development 快速且可扩展的开发 Modern OS platforms, hardware architectures, and environments 现代操作系统平台、硬件架构和环境 Interoperability with and migration from existing C++ code. 与现有C++代码的互操作性和迁移。 The development team will also set out to create a built-in package manager, something that C++ sorely lacks. 开发团队还将着手创建一个内置的包管理器,这是C++非常缺乏的。 Here is some C++ code translated into Carbon. First, the C++ code: 这里是一些C++代码翻译成Carbon。首先,C++代码:PART 03 前景:Rust会登顶吗?
谷歌推出Carbon,C++的实验替代品 Carbon
Here is the same function written in Carbon:
下面是用Carbon写的相同函数:
The development team plans to write translation tools to migrate C++ code into Carbon code.
开发团队计划编写翻译工具,将C++代码迁移到Carbon代码中。
Why Not Rust Then?
那为什么不是Rust呢?
Rust was another recent language built specifically to address the needs of memory-safe performance applications. So why not just use Rust then? In his presentation at CPP North, Carruth advised those using Rust to continue to use it. Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust. Carbon is specifically what Carruth called a “successor language,” which is built atop of an already existing ecosystem, C++ in this case.
Rust是另一种最近开发的语言,专门用于满足内存安全性能应用程序的需求。那么为什么不直接用Rust呢?在CPP North的演讲中,Carruth建议那些使用Rust的人继续使用Rust。Carbon是为那些已经在C++中拥有大量代码基的开发人员设计的,这些代码基很难转化为Rust。Carbon就是Carruth所说的“后继语言”,它建立在已经存在的生态系统之上,在本例中是C++。
“It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers,” the documentation explains. This means the language should be as performant as C++, it should provide seamlessly, and offer bidirectional interoperability with C++.
“它是围绕与C++的互操作性以及现有C++代码库和开发人员的大规模采用和迁移而设计的,”文档解释道。这意味着该语言的性能应该与C++一样,它应该无缝地提供,并提供与C++的双向互操作性。
Google’s #Carbon programming language reminds me of the approach Apple took going from #ObjC to #Swift. In my experience that was a really good approach. It made porting Objective-C code to Swift a lot easier, since you never had to do a full port.https://t.co/dQK5wV0J0B
谷歌的Carbon编程语言让我想起了苹果从ObjC到Swift的方法。根据我的经验,这是一个非常好的方法。这使得将Objective-C代码移植到Swift变得更加容易,因为您永远不必进行完整的移植。https://t.co/dQK5wV0J0B
— Erik Engheim (@erikengheim) July 20, 2022
-埃里克·恩海姆(@erikengheim)2022年7月20日
微软想通过TypeScript 革了JavaScript的命
苹果想用Swift革了Objective-C的命
JetBrains 想用Kotlin 革了Java的命
现在,Google终于要拿C++开刀了。
这个黑色圆圈中的C可不是C语言,而是叫做:
Carbon
为啥Google要搞一个Carbon呢?C++不是Google的五大语言之一吗?
C++,Java,Python,JavaScript,Go
长期以来,C++是构建性能关键型应用程序员的主要语言,也积累了大量的项目和类库。
但是C++本身非常复杂,数十年下来,这些项目和类库慢慢变成了技术债务。
C++虽然也在努力发展,但是受到了官僚委员会流程的阻碍,这个流程以标准化而不是设计为导向,添加新功能很困难,一个特别委员会可能需要数年的瀑布流程才能做出重要决定。
可以想象,当Google的人面对着海量C++代码的系统,想改进C++又很难的时候,那种无奈的心情。
既然如此,那就重启炉灶,用碳(Carbon)去燃烧C++吧!
为什么不直接用Rust?
可能很多人有这个疑问,Rust也面向系统级编程,并且被Mozilla设计成内存安全的语言,用来替代C语言。
Google认为,对于新项目来说,用Rust很合适,但是问题在于:
它不像 Java 和 Kotlin 那样具有“双向互操作性”,C++的生态迁移到Rust是很困难的。
而Carbon的目标是C++的后继,是围绕与C++的互操作性以及迁移现有C++代码库而设计的。
不得不说,生态的威力再一次展现,当你想让别人搬家的时候,最好能把他手头的财产一并都搬走,否则每个人都会恋恋不舍。
Carbon的设计目标是这样的:
性能要和C++相媲美,要不然就没有吸引力了
和C++无缝的,双向的互操作
代码应该容易编写、阅读
有着实用的安全和测试机制
要有一个温和的学习曲线,别把人都吓跑了
支持现有的软件设计和架构
开发团队还将着手创建一个内置的包管理器,这几乎是每个语言必备的工具了。
这样,Carbon就可以像TypeScript和Kotlin那样,基于现有C++的生态系统,吸引开发人员,保护现有投资。
看下Carbon的代码吧:
import Console; // Prints the Fibonacci numbers less than `limit`. fn Fibonacci(limit: i64) { var (a: i64, b: i64) = (0, 1); while(a < limit) { Console.Print(a, " "); let next: i64 = a + b; a = b; b = next; } Console.Print("\n"); }
用fn来定义函数,用var 来声明变量,变量类型后置,有Go语言的影子。
用大括号定义函数体和代码块,用分号来分割语句,while 关键字, 有C语言的感觉。
Console.Print(...),有点C#的味道。
总之,虽然号称是C++的后继,但一点儿也不像C++。
语言特性
我浏览了一下,感兴趣的特性有这些:
指针
指针号称是C语言和C++的精华,可以直接操作内存,强大又灵活。
不过指针也是万恶之源,把指针指向不该指向的地方,程序马上崩溃。
Carbon中也有指针:T* p , 但是为了安全,并不支持指针的算术运算如 p++
Carbon中没有空指针,要指向一个无效的对象,需要使用Optional(T*)
既然有指针,还要和C++互操作,那垃圾收集之类的技术肯定是没法用了,自己小心地管理内存吧。
只提供一种方法来做事情
对于一件事情,Perl语言提供了很多方式来做,在非常灵活的同时也让代码维护者非常困扰。
C++也是这样,例如可以用 "&&" 或者 "and"来表示逻辑运算,可以用struct 和class 来封装数据。可以用0xaa和0xAA表示十六进制。
为了提高代码的可读性和可维护性,促进团队协作,Carbon决定向Python学习:应该只有一种最好的,最明显的方式来做事情。
安全
Carbon 对软件的考量是这样的:
内存安全:不允许越界访问,取消null指针,取消未初始化的指针,禁止访问已经释放的地址
类型安全:不允许用不正确的类型来访问有效的内存
数据竞争安全:防止多个线程在没有“同步”的情况下对内存地址进行读写
其他的特性例如泛型、类.....我这里就不一一赘述了,感兴趣的可以到GitHub上去看看:
https://github.com/carbon-language/carbon-lang
开发方式
Carbon 是Google内部发起的,但是Carbon团队认为为了未来取得成功,未来需要独立的、开放的社区来主导。
不能像C++委员会那样,虽然保证了国家和公司的代表性,但是限制太多,成本高昂,不出席会议就没有发言权,只有现场人员的投票才能决定。
这和现在的主流开源方式大相径庭,所以Carbon不走“ISO流程”,要拥抱开源,将来由软件基金会和志愿者领导。