在这篇文章中，我将尝试比较 golang、zig 和 rust。以及为什么 rust 赢得了这次比较（对我来说）。
故事时间！
我用 golang、zig 和 rust 编写了 3 个项目。这些项目足够大，可以很好地了解语言基础、缺点以及语言、框架或生态系统是否存在问题。
提示：请随意跳转到 tldr 部分以获得该死的答案。
go语言
几个月前我开始构建开发者工具，最初使用 golang。
第一个是基本的数据库管理和迁移实用程序 (dbdaddy)，我真的很喜欢使用 golang。
尽管这是我第一次尝试用 golang 构建比 advent of code 和 10 亿行挑战问题更严重的东西，我很惊讶我花了不到一周的时间就精通了它 .
之字形
一直以来，我都在和 zig 一起玩（没什么太严重的）。我听说 redis 将其许可证更改为“技术上非开源”许可证。
我心想：在 zig 中构建一个新的开源 redis 有多难？
快进 2 个月后：该死。
“gbcache”背后的基本思想是基于 lru 的内存缓存，但实际的事实来源是保存在磁盘上，以及诸如引起的特定键/值更改的通知以及分配给键的 ttl 之类的功能。
zig 的明确性令人印象深刻，这使得它变得更加简单且更容易使用。
我从“如果明天要使用 hyperscale™，它能处理负载吗？”的角度启动了 gbcache
这个观点驱使我排除了 golang，因为如果我无法极其确定地推理内存分配，我将无法完全控制速度。
从这个角度做事是一次非常好的学习经历，因为突然你开始看到程序中可能崩溃、耗尽内存或可能成为瓶颈的所有点 –代码中的热路径.
由于 zig 的明确，我确定了我在何时何地分配内存。
但是…zig 归根结底并不是一种记忆安全的语言，而且我是一个技能问题与珠穆朗玛峰一样大的人。
进入铁锈
在过去 2 年里，我曾 3 次尝试并愤怒地退出 rust。来自 JavaScript 背景，我们的 macbook m69 maxes 中有大量 gb 内存，我从来没有真正理解为什么 rust 有这些规则，并且从炒作的角度来看待它可能是一个糟糕的角度.
尽管我多次愤怒地退出，rust 仍然在我的脑海中，它奇怪的语法、令人沮丧的内存规则和令人难以置信的生命周期。
但是在写 zig 时，有件事让我受到了打击…我已经在跟踪所有这些记忆规则和生命周期，但这是一种精神负担。
我开始注意到 zig 代码中的模式和样板，试图做 rust 已经做的事情。
锈
在为 sfs（sfw 名称 – “简单文件存储”）构建 cli 客户端时，我决定再次尝试 rust。
这一次，在翻阅这本生锈的书时，我开始感受到这一切的“原因”。
我喜欢 rust 的最基本的一点是基于所有权和借用的记忆的心智模型。
尽管这种拥有和引用的记忆模型是虚构的，但它是一种方便推理的心智模型，并且在我的头脑中产生的开销更少。
与 c 和 zig 等语言在您头脑中产生的经典心理记忆模型相反。 必须在脑海中跟踪各个内存分配及其生命周期吗？不用了，谢谢！
总长dr
go语言
- 快（就像你的 5 个月活跃用户会需要它一样）
- 可靠
- 愚蠢的简单，语言永远不会成为你和你的目标之间的障碍
- 伟大的软件包生态系统
之字形
- 速度极快
- 愚蠢的简单
锈
- 速度极快
- 可靠
- 伟大的软件包生态系统
他们全部
- 惊人的错误处理
如果你是一名日常普通的后端工程师，并且喜欢计算他们的冲刺性能，那么你最好的选择可能是golang。
“但是我的公司不使用 gola——” “离开公司，离开它，为工具使用正确的工作。离开公司。”
对我来说，golang 就像一场包办婚姻，你内心永远不会感到那种匆忙，但它永远不会让你失望，它是你的生死攸关的伴侣，你可以把你的一生都押在它上面它。
但是我的朋友，如果您正在寻找那种高峰，请继续阅读！
鲁斯特·普兰
但是我想要那种冲动…我想要看到他们的眼睛语法时我的心爆炸…当我和他们在一起时，我想要感觉自己在天堂见鬼，当我不…
让我们快速看一下 rust 中多线程安全的示例。
use std::thread; fn main() { let mut counter = box::new(0); // 32-bit integer allocated on the heap let mut handles = vec![]; for _ in 0..10 { let handle = thread::spawn(|| { *counter += 1; // trying to edit the value }); handles.push(handle); } for handle in handles { handle.join().unwrap(); // waiting for all the threads to complete } println!("result: {}", *counter); }
此代码不安全地访问计数器变量，因为所有线程都会尝试同时修改计数器。
在其他语言中，类似的代码会愉快地编译和运行。
如果您以前在多线程环境中工作过，您的第一个想法可能是使用“互斥体”来防止更新计数器变量时的竞争条件。
但是由于人为错误，在大型代码库中很容易错过这样的小事情。
rust 甚至不允许这个程序编译。
由于所有权和借用规则，编译器将检测到您在 for 循环的第一次迭代中的第一个线程中可变地借用计数器…到目前为止还好…第二次迭代还想可变地并行借柜台？ 不安全！引发编译时错误！！。
出于变异/修改的目的而从其所有者处引用或“借用”值称为“可变借用”
src/main.rs|8 col 36-38 error| cannot borrow `*counter` as mutable more than once at a time `*counter` was mutably borrowed here in the previous iteration of the loop
在这种情况下，其他语言根本不会给你任何错误。检查正确性是你的责任，rust 会阻止这种情况发生。
像这样在语言中传播的结构可以帮助你避免搬起石头砸自己的脚（经常）。
结论
这要看情况！
我真的希望有一种语言能够答案，即使 golang 非常接近这个目标，它实际上取决于您的用例，最重要的是您的团队。
对我来说，与 rust 合作很愉快（现在，谁知道呢……呵呵）
tigerbeetle 的人们在 zig 上尝试了一次机会，他们对此很满意。
primeagen 对 zig 更满意。
对于 jarred sumner 来说，zig 很好，他用 zig 写了 bun。
mitchell hashimoto（hashicorp 背后的人）正在 zig 中书写幽灵，这是一个速度极快的术语 —
.
.
.
等等…
