使用Rust三年多了，我非常喜欢它。Rust不仅帮助我完成了很多任务，还开发出极其可靠的软件。Rust让推断代码的并发性和并行性变得更容易。         

我可以继续赞美Rust，但这并非本篇文章的重点。相反，这篇文章旨在揭露Rust的一些缺点，它有时会拖慢开发人员的进度，需要调用其它语言才能完成任务。

Rust需要调用其它语言完成任务          

Rust中没有具体调用系统命令的方法，得通过crates.io实现此功能。7年前，syscall crate进行了最后一次更新，支持以下平台：               
毫无疑问，Linux在列表中出现次数最多。         
不过，如果你仍只使用FreeBSD操作系统而不使用x86_64，你就out了。如果你只关心NetBSD、OpenBSD或Solaris，你只能get到普通的技能。此时，你可以采取的措施是使用libc crate。       
我认为这些方式都不太好，这不是系统编程语言该有的状态。系统编程语言应该可以与其它编程语言互操作，不需要通过调用C语言完成任务。         

内存模型：用Rust语言开发Linux内核的拦路虎          

上述列表中出现最多的当属Linux。最近几年，Rust For Linux项目随着Rust的火爆也开始逐渐升温。但是，Rust想深入Linux的真正核心仍有很长的路要走，最大的拦路虎是内存模型方面的问题。         
当Rust编写“无限接近计算机底层”的操作内核时，内存模型会变得很重要。它是多线程环境能够可靠工作的基础，需要对多线程环境的运作细节进行完备的定义。         
Rust中的lock锁是与具体要保护的数据是有强绑定关系的，开发者需要调用data.lock将锁进行锁定，只有这样才能受锁保护的数据才能被访问。         
由于Rust的变量都是有严格的生命周期及借用机制的，因此，锁也很可能要在内存中移动，内存中对象的移动、所有权借用等除了造成移动锁之外还会有移动构造函数等问题。
但是移动锁、还移动构造函数这些概念在之前的Linux中几乎是闻所未闻的。这些问题在Rust只开发上层应用时都不是问题，但一旦深入到操作系统内核，这些就都成了问题。所以，Rust想真正深入到Linux的内核当中还有很多的路要走。     
麻烦：你只在GitHub上才能获得crates包         
一旦部分技术人员放弃使用crates包，随着时间的推移更多人会放弃。我并不是唯一批判这个系统缺陷的人。         
最重要的是，crates.io的注册列表只在GitHub上才能get到。这意味着，为了使用crates.io，你必须拥有一个GitHub帐户。对于一些开发人员来说，这显然不是问题，但是，并不是所有程序员都能够适应这种形式。         
总之，就个人而言，我认为Rust在GitHub上托管他们的代码糟糕透了。

不吐不快：Rust中那些突出的缺陷          

除了上述的“吐槽”，Rust编程语言还有一些明显的缺点，在这里做个总结：         

编译时间           

与其对等的编程语言相比，Rust编译代码的速度相对较慢。原因是它的“编译单元”不是单个文件，而是上文提到的crate包。         

crate可以包含多个模块。因此，它们可以是大型编译单元。虽然完成了whole-of-crate优化，但是，它还需要whole-of-crate编译，这很耗时。此外，它还具有一个复杂的编译器工具链，该工具链包含多个中间表示，并向LLVM发送大量代码。这些都是导致Rust编译代码速度变慢的原因。

学习难度   

真正学会Rust很难，为了理解它的主要部分，你需要先熟悉C++ 或任何面向对象的语言。

过于严格   

在编程方面，严格通常被认为是一件好事，但是，Rust有时有点过于严格，使用它进行编程时很难偷懒。直到一切都恰到好处，程序才会正确运行。        

替代品：Zig，小巧而简洁        

除了Rust，另一种真正引起我注意的语言是Zig。它在编译时计算和执行命令，而不是像Rust一样在运行时执行命令。很多程序员已经通过实践证明了这一点。Zig不仅成为了完美的替代品， 对于维护任何类型的宏观系统也都游刃有余。         
Zig编程语言最主要的优点是小巧而简洁，正广受程序员好评。它专注于调试你的应用程序，而不是调试你的编程语言知识，没有隐式控制流、没有隐式内存分配、没有预处理器，更没有宏。  此外，用Zig编写的库可以在任何地方使用，包括：桌面程序和游戏、低延迟服务器、操作系统内核、嵌入式设备等。         
Zig还提供了defer和errdefer，使所有的资源管理（不仅是内存）变得简单且易于验证。         

写在最后：Rust仍是理想语言          

总之，抛开上述缺陷不谈，我仍认为Rust非常接近我的理想语言。但实际上，我也正在寻找其它语言。         
我相信，当听到批评的声音后，Rust可以已经开始变革并反思了，也许，更好的解决方案即将出现。这需要一群人共同改进这种语言才不会重复同样的错误。         
当然，我对Rust抱怨主要针对crates.io，相信此类问题在不久的将来都能得以解决。
所以，无论如何，让我们尽情幻想“后Rust时代的理想语言”。这种语言应该与Rust类似，同时具有Zig语言comptime的优势。         
新的语言中会有borrow checker，它就像Rustc编译器一样可以检测出错误的消息。我们也会更多的支持comptime概念的出现而并非宏。与Rust不同，这种新语言能够从头至尾完成各种任务。         
在新语言中，我们可获得接口等内置功能并能够直接与其它语言以及底层操作系统内核通信。最后，我还设想出一个库包生态系统，它将是完全分布式和去中心化的。         

虽然Rust有缺点，但它仍然是迄今为止在内存访问、安全性和准确性方面最好的语言。我提到的很多小抱怨都只是从普通程序员角度出发的。

以上就是“这些坑，Rust早填为妙！”的详细内容，想要了解更多IT圈内资讯欢迎持续关注编程学习网。