INTRODUCTION

引言：一场由编程语言迁移引发的行业论战

2026年，高性能JavaScript运行时Bun的创始人贾里德·萨姆纳（Jarred Sumner）发布长文，宣布项目已从Zig语言全面迁移至Rust，并详细解释了迁移的技术背景与工程收益。很快，Zig语言创始人安德鲁·凯利（Andrew Kelley）发布言辞激烈的回应，控诉双方长期以来的合作矛盾，甚至直言萨姆纳“在接触大语言模型之前，就一直在写糙代码”。

这场充满个人情绪的公开骂战，迅速演变为全行业的讨论焦点。但剥开恩怨外壳，它本质上撕开了软件开发行业延续数十年的核心分歧：代码生产究竟该是匠人打磨作品的工艺过程，还是标准化、自动化的工业流程？本文将沿着历史脉络，从格式争论、语言设计、安全机制到AI革命，逐层拆解这一命题的深层逻辑。

01

制表符与空格：一场被工具终结的审美战争

关于代码缩进用制表符还是空格的争论，几乎和现代编程语言一样古老。早在1988年的Usenet新闻组comp.lang.c中，就有人断言“制表符天生邪恶”；到2007年的Ruby社区，这场争论仍被称为“哲学级口水战”；甚至美剧《硅谷》中，主角因对方用空格缩进而终止约会的桥段，更让它成为程序员文化的标志性符号。

这场看似毫无意义的“自行车棚效应”式争论，背后藏着早期软件开发的工艺属性：代码风格是开发者专业审美的延伸，缩进、换行、括号位置等细节，承载着个人对“优雅代码”的理解，也是身份认同的载体。作者回忆入行初期，资深工程师会因格式不符合个人标准直接打回代码，新人要花大量时间学习团队的“专属风格”，甚至仅凭排版就能判断出代码出自谁手。

这一变化的代价清晰可见：代码失去了个人与团队的“笔迹”，所有个性、趣味与实验性都被打磨成统一的工业标准件。但收益同样明确：团队协作的沟通成本大幅降低，开发者不再需要为审美分歧消耗精力，可以将注意力完全集中在功能与逻辑本身。正如Go团队核心成员拉斯·考克斯（Russ Cox）所言：“让gofmt帮我格式化代码是一种解放——我终于有更多脑细胞去解决真正有趣的编程问题。”

02

Go语言的设计哲学：工业化生产的语言范本

如果说格式化工具是软件开发工业化的表层体现，那么Go语言的诞生，就是工业化逻辑在语言设计层面的集中落地。

Go由肯·汤普森、罗布·派克等Unix先驱在Google内部设计，初衷是解决大规模C++项目编译慢、门槛高、协作难的痛点。罗布·派克曾直白地表述Go的设计目标：Google的工程师大多是刚毕业的年轻人，他们不懂复杂的C++模板元编程，但我们需要让他们也能写出符合Google规模的高性能代码。

从经济学视角看，这正是典型的去技能化（Deskilling）与工作强化（Work Intensification）：通过技术工具降低岗位对专业技能的要求，同时通过更快的编译速度、更简单的语法规则，提升单位时间的工作产出。Google投入资源研发一门语言，本质是为了用更低成本的人力，完成更多的开发工作。

这一设计带来了双向影响：一方面，它消解了资深C++工程师的职业议价权——那些积累了十年的模板优化、内存调优经验，在Go的简单语法体系下失去了用武之地；但另一方面，它大幅降低了高性能后端开发的门槛，让更多普通开发者能参与到大型软件的构建中。这正是工业化的典型特征：专业门槛让位于生产效率，个人技艺让位于标准流程。

03

手工工具与电动工具：工艺精神的现实边界

在工业化的洪流中，始终存在着坚守“软件工艺”的群体，而Clojure社区是其中最具代表性的一派。

Clojure创始人里奇·希基（Rich Hickey）推崇“简单优于容易”的理念，倡导“吊床驱动开发”——开发者要深度思考、用少量精巧的工具构建高质量系统。这种思想极具感染力：它将编程塑造成一种匠人工作，强调个人思考的深度、工具的 mastery（精通），以及代码作为作品的质感。很多开发者会被这种理念吸引，甚至想方设法把Clojure等小众语言引入企业项目，以此对冲日常CRUD开发的枯燥感。

作者用木工行业做了一个精妙的类比：在工业生产领域，电动工具早已全面普及，没人会质疑工厂用电锯、电刨的合理性；只有在业余爱好者圈子里，才会争论“手工工具党（Neanderthal）”与“电动工具党（Normites）”的优劣，双方各守乐趣、互不干涉。

但软件行业存在明显的错位：很多秉持工艺理念的开发者，总想把自己钟爱的“手工工具”——小众语言、个性化范式、极致的个人风格——带进工业生产环境。作者坦言自己也曾有过这种心态：本质上是用“工艺感”弥合“自我认知为匠人”与“实际工作是流水线环节”的认知失调。

04

安全带与类型系统：安全规范的强制化之路

关于“要不要强制安全机制”的争论，在软件开发中同样有一个绝佳的现实参照：汽车安全带的普及史。

三点式安全带1959年由沃尔沃发明，1968年美国强制要求所有新车安装，但民众佩戴率极低。1974年美国政府曾推行“点火联锁”装置——不系安全带汽车就无法启动——结果引发全民抗议，国会不到一年就废除了该规定，甚至禁止政府再推行类似机制。直到80年代各州逐步立法、长期科普教育后，安全带才从“侵犯自由的强制规定”，变成全民共识的安全常识，最终拯救了数十万人的生命。

作者将编程语言的安全特性比作代码世界的安全带：强类型检查、内存安全保障、编译期并发校验，就是防止程序“出事故”的防护装置。Rust的借用检查器会在编译阶段杜绝绝大多数内存泄漏、悬垂指针、数据竞争问题，就像安全带在碰撞时保护乘员一样。

这也正是Bun从Zig迁移到Rust的核心动因之一：萨姆纳明确提到，Zig的手动内存管理带来了大量稳定性隐患——每一次内存分配、释放都需要人工严格审查，稍有疏漏就会引发泄漏甚至崩溃；而Rust能在语言层面系统性地杜绝这类错误。

作者对“强制安全”持辩证态度：他反感体验糟糕的强制机制——比如故障频发的点火联锁，或是晦涩难用、徒增开发成本的类型系统；但坚决反对“我能写出安全代码，所以不需要安全机制”的自负。无数线上事故证明，个体的审慎永远替代不了系统级的安全保障。

05

“糙代码”悖论：质量的主观性与自动化的边界

安德鲁·凯利那句“早在有LLM之前，他就在写糙代码”，引出了全文最核心的概念：slop（糙代码）。

“糙代码”的词义一直在随技术变迁：早期黑客行话里，它指编译器生成的、比手写汇编更冗余的机器码；格式化工具普及后，它指开发者随手写出、交给工具整理格式的初稿；到了AI时代，它又被用来指代大模型生成的、缺乏设计感的低质量代码。

由此延伸出“软件工匠”的双重标准悖论：软件工程师的本职工作，就是用代码自动化其他行业的劳动，坚信机器能比人做得更高效、更可靠；但很多人却坚信“写代码”这件事本身不能被自动化，只有人类工匠才能写出高质量代码。在作者看来，这是一种深刻的职业傲慢——既然软件的使命是自动化，那么编码工作本身的自动化，只是行业发展的必然结果。

06

AI时代的终局：工业化加速与工艺的转向

基于对行业历史的梳理，作者对AI时代的软件开发走向做出了一系列判断：

CONCLUSION

结语

Bun的迁移风波，只是软件开发工业化长途中的一个注脚。从制表符争论到格式化工具，从手工汇编到优化编译器，从全手写代码到AI辅助编程，行业一直在沿着“标准化、自动化、工业化”的方向前进。软件开发一直在“吃掉自己”：每一次技术革新，都会重构自身的生产方式。

我们不必为手工编码时代的逝去过度感伤。木工行业发展了数千年，依然有人热爱手工刨削的质感，但没人会要求工厂放弃电锯回归手锯。软件行业也一样：工匠精神会以新的形式延续，而生产的车轮，永远会向着效率与规模的方向滚动。

INFORMATION SOURCE

信息来源：本文核心观点、案例与论述均整理自 Powderworks 于2026年8月12日发布的专栏文章 Tabs, Spaces, Hand Tools, and Seat Belts，原文发布于 Powderworks 通讯（newsletter.powderworks.dev）。