为什么我现在还不能从Rust完全转到Zig

照片由 Dominik Scythe 拍摄，来自 Unsplash

说实话，我确实喜欢写C语言。

我知道这有点不理智，但是用 C 语言编程就是感觉对路。也许是因为我在为 Linux 内核做贡献的过程中，花了很多时间用 C 语言编程。那段时间真是美好，因为有机会向世界上一些最好的 C 语言程序员学习。在 Linux 内核上开发也让我理解了 C 语言程序和它编译成的机器码之间的联系，这一点也许也影响了我的思维方式。

然而，C 是一种不安全的语言。很容易犯错。但我花了无数个小时调试 C 程序，最终变得相当熟练。我经常能从 Linux 内核的寄存器转储（也就是他们所说的“oops”）中找出问题所在，并修复一个无法重现的 bug。我也学会了如何编写更少错误的 C 代码。我觉得用 C 语言编程还挺有效率的。

C 也是一种底层语言。当你用 C 语言编程时，你会发现即使是最简单的任务也需要编写大量的代码。C 语言中没有内置的数据类型，所以每次我需要一个哈希表或链表时，通常都是自己实现的。而且我几乎不使用二叉搜索树，因为自己实现一个二叉搜索树需要花费很长时间才能正确完成。也许 C 并不完美呢？

我也在两个不同的工作机会中写了相当多的C++代码。C++11及其后续版本的现代化努力带来了很大的改进。你现在可以使用各种数据结构和算法，而且利用类和模板等功能，你可以用更少的代码实现更多功能。然而，C++继承了C语言的不安全性，这意味着你仍然需要花很多时间调试你的代码。

当 Rust 在 2015 年出现时，我对它的内存安全承诺非常感兴趣。当时我做了一些 Haskell 编程，并觉得这两种语言——尽管针对完全不同的应用场景——都共享了“编译通过即表明代码无误”的理念。借用检查器能够消除你经常会遇到的 C 语言中的一类问题，这一点感觉非常神奇，简直像魔法一样。不过，在探索了一段时间该语言后，我放弃了，因为工具一直在不断更新，坦率地说，我对借用检查器还是一头雾水。也许我被 C 语言的思维定势束缚住了。

到了2021年，我开始在专业上使用Rust编程。我知道自己不希望用C或C++，而且我的联合创始人Glauber在使用Rust时也有很好的体验，所以我们选择了Rust。我大概花了两到三个月的时间与借用检查器斗争，直到开始更加得心应手。确实如此，我当时还是在用C的思维方式。后来我发现了Send和Sync特性，它们在多线程程序中非常有用。自2015年以来，工具和生态系统也发展迅速。经过最初的陡峭的学习曲线，使用Rust编程变得非常高效。

但 Rust 真的是门复杂的语言。我写 Rust 写得越多，就越觉得它太复杂了。用 traits 或异步 Rust 时，事情开始变得复杂起来。可能我还在用 C 语言的思维模式。

我认为在2022年的某个时间点，我因为两个项目Bun和TigerBeetle而发现了Zig。就像2015年接触Rust一样，我开始探索Zig。很快我发现我真的很喜欢Zig，因为它感觉就像C语言！但是就像Rust一样，经过初步探索后，我决定放弃它，因为工具一直在不断更新，生态系统还不是很成熟，不适合我。

2023年的夏天，我想给Zig再试一次，部分原因是Glauber一直在提这个想法。我决定尝试用Zig写一个小的SQLite克隆，作为概念验证。随着工作的开始，我发现Zig是一种底层语言，但不像C那样，而是比Rust更底层。但我认为这是一笔可以接受的代价，因为Zig用起来就是很顺手。在编写数据库时，我需要一种高效处理I/O的方法。在阅读TigerBeetle的源代码时，我发现了Michell的libxev，甚至为此做了一点贡献。但经过三个月的周末攻关后，我最终将代码转换成了Rust，并再次感到效率满满。

尽管我仍然非常喜欢Zig，为什么我最终选择了Rust而不是继续使用Zig？

首先，comptime感觉像是一个hack。这可能有点儿不合理，但我就是不太喜欢comptime这种感觉。实际上，如果不能有泛型，我更倾向于使用C语言的老式预处理宏。但我还是觉得Zig最好还是要有泛型。

你还是不断遇到 SIGSEGV。 我不知道是不是我在 Rust 上过于纠结，结果写了很多愚蠢的错误，导致了段错误，然后我用调试器追踪这些错误。当然，如果我再多写一些 Zig 代码，这种情况可能会有所好转，但我已经习惯了 Rust 的借用检查器。

你也开始泄露内存了。 再次说来，这可能是因为我太习惯于用 Rust 的思维方式来思考，结果我经常写出会泄露内存的代码。当然，Zig 在这方面也有很好的工具可以快速捕捉到这些问题，所以看来可能也不是什么大问题。

关于Zig的书一本都找不到。 我特别需要一本好的技术书来学习Zig，但是关于Zig的书却找不到，学Zig就感觉特别难。相比之下，有很多关于Rust及其相关主题的好书。

生态系统可能还没有形成。 有两个大型 Zig 项目，Bun 和 TigerBeetle，它们是非常好的学习资源；但是，目前还没有像 Rust 那样庞大的生态系统可以利用。工具链可能还不太完善，Zig 自身提供的工具链很棒，但它们仍在不断变化，就像 2015 年的 Rust 一样。但更关键的是，第三方工具如 Github Copilot 等还不是很成熟。

行业投资还没有到位。 我们的行业普遍使用 Rust。对我来说，转折点是微软开始用 Rust 编写 Windows 的一些部分，以及 Linux 内核引入了对 Rust 的支持。仅这两件事就足以说明 Rust 很可能会长期存在。相比之下，Zig 当前的行业支持还不像 Rust 这样广泛。但这并不意味着 Zig 最终不会达到类似 Rust 的行业地位，但目前 Rust 是一个更安全（也更乏味？）的选择，对于大多数开发者来说更为稳妥。

我真的很喜欢Zig。但我现在还不是很准备切换到它。Rust并不完美，但它现在是我系统编程的首选语言。使用它时我感觉效率很高。Zig可能就和2015年的Rust差不多，它可能只需要更多的时间。不过对我而言，我会等第一本书出来，然后回头再看看。我也希望也许他们会为像我这样的用户提供一个更简单的comptime替代方案。但在那之前，我将继续开心地使用Rust。