为什么使用 Rust 进行系统编程？
归结为内存安全性、性能、强大的开发人员生态系统以及 Rust 提高开发人员生产力的潜力。
如果你在做系统编程，那么你没有太多选择。我来介绍一下背景，我是一个长期从事 C 语言编程的程序员。我喜欢 C 语言，但它并不是构建当今基础设施软件的可行选择。
Rust 是构建大部分基础设施的语言。归根结底是内存安全，而 Rust 确实能够突破这个上限。
世界上大约有 700 万 C++ 开发人员，现在有 100 万到 200 万 Rust 开发人员。
在实践中，如果您使用带有 Rust 扩展的 Visual Studio Code 之类的东西，IDE 可以很好地识别问题。
- Rust 不存在“开发周期速度”问题。
为什么要考虑 Zig？
用 Rust 重写所有内容？
不一定。随着讨论的继续，话题转向了 Zig。Rust 优先考虑安全性和性能，而 Zig 则提供：
- 低级控制：与 Rust 相比，Zig 的控制级别较低，这对那些因 Rust 的抽象限制了对系统调用的控制级别而感到沮丧的开发人员很有吸引力。
- C 互操作性：Zig 使与 C 库的交互变得更加容易，这在使用现有的基于 C 的系统和基础设施时非常有帮助。
- 自包含的二进制文件：Zig 可以生成不需要任何依赖项的自包含二进制文件——这比 Rust 的构建和分发过程有很大优势。
- 易于理解的标准库：Zig 的标准库比 Rust 的标准库更具可读性和易理解性，这使得整个语言更易于使用。
Zig的“编译时”编程复杂且难以使用，尤其是与 C 预处理器方法相比。
- 它实际上是一个强大的功能，避免了像其他系统语言那样需要“语言中的语言”。
开发人员欣赏 Zig 在某些领域的简单性，尤其是它的元编程方法，有些人认为它比 Rust 的方法更简单。
然而，人们对 Zig 的安全性和稳定性存在担忧，批评者指出它可能不如 Rust 那么强大，特别是在处理内存管理和潜在的段错误方面。
Zig 确实很棒，因为没有隐藏的行为。你不能做诸如运算符重载之类的事情。
- 由于没有构造函数和析构函数，因此很容易弄清楚发生了什么。
在 Zig 中使用 C 库真的很容易。我们使用了许多 C 库以及 libc 内容。
Zig 确实非常擅长为所有东西生成二进制文件——这些二进制文件不依赖任何东西，可以在任何地方运行。
- 你可以用 Rust 做到这一点，但唯一能做到这一点的工具实际上是在构建过程的一部分中使用 Zig。
系统级语言的未来：Mojo 崛起？
Mojo 被定位为系统级语言，因此它似乎与这场辩论有关。
提高 Python 性能的门槛真的很低，Python 在机器学习中找到了属于自己的一席之地。这种情况已经持续了一段时间，而这似乎是 Lattner 开发 Mojo 的方向。也许我只是根据以前的经历产生了偏见，但我只是不想象自己会在 Python 提供的抽象级别上编写系统软件。
这不仅仅关乎速度和性能：
- 通常，你需要做一些截然不同且极其具体的事情——这就是我们在 Linux 内核中使用大量汇编的原因。C 编译器不可能生成我们为某些特定功能（如替换进程的页表）所需的代码。
- 在系统编程中，你经常会遇到没有编译器会生成你需要的代码的情况，因为这不是它们设计的目的。
例如可以绕过 libc 直接进入系统调用级别。这种情况在数据库中也经常发生。
- Rust 和 Zig 可以让你非常轻松地做到这一点。
- Python 语法提供的正常抽象太高了。
- 对于机器学习，我认为 Mojo 将带来变革。ML 生态系统非常耗电，但 Python 在这方面真的很糟糕。
Mojo 不是 Python——它只是窃取了 Python 语法，并且有一个借用检查器。
- 但是，人们在将计算变成基于 GPU 的方面下了很大的赌注。
- SIMD 将成为每种想要成为“下一个大型系统语言”的语言的必经之路。
Zig 具有 LLVM 向量类型：它既可以在 ARM 64 上运行，也可以在 x64 上运行。
- 通常，您必须编写一堆特定于体系结构的代码才能拥有 SIMD。
- 为什么不直接使用 C++？
- 它有唯一的指针，它有共享的指针。
- 既然你可以直接使用 C++，为什么还要使用所有这些新语言呢？