LLM 让 Rust 和 Zig 等硬核语言更流行
Fast and Hard Code
Twitter 上流传着“编程已解决”的梗，这并非空穴来风。随着 LLM 的普及，语言选择的重要性正在下降，开发者不再受限于自身熟悉的语言，转而更关注软件的性能。作为长期的 Rust 程序员，我观察到 Mitchell Hashimoto、Daniel Lemire 等对性能有执念的开发者，正积极利用 AI 代理编写代码。如今，Cloudflare 的 Artifacts 服务采用纯 Zig 引擎，Vercel 也推出了基于 Zig 的 fx 代理。更令人惊讶的是，开发者们开始涉足 DWARF 文件、eBPF、自定义网络驱动等曾经被“守门人”垄断的硬核技术。AI 不仅降低了门槛，或许还让更多追求极致速度与体积的开发者涌现。
LLM 使得语言选择不再像过去那样具有决定性，因为如果你不喜欢某种语言，似乎可以将其重写为另一种，甚至让 AI 选择一种你完全陌生的语言。
HN 评论区
79- qsera
> 突然间，我看到人们利用 DWARF 文件、eBPF、自定义网络驱动、自定义加密算法以及非常古老的计算硬件做出了一些令人印象深刻的成果。过去，许多开发者根本无法触及这些领域。在某些情况下（例如加密），你甚至会被劝退，因为这些东西被“圈内人”有意设下了门槛。
过去，至少我们中的一些人被迫去理解这些东西，因为如果不理解，就无法完成我们真正想做的事；其中有些人因此产生了热情，继续深挖，甚至有些人基于这些经验做出了更优秀的东西。
现在，没人需要理解任何东西了，而我们也将永远无法得到更好的成果。
- willtemperley
我觉得这在一定程度上是对的，但这真的取决于 LLM 在某个主题上掌握的信息量。
它们在数学方面表现惊人，因为数学从第一天起就是开源的。算法方面也很强，原因类似。C 语言绑定更是小菜一碟，因为现成的参考案例太多了。但它们在使用语言的前沿特性时却一塌糊涂，因为相关数据还很少。
基于这一点，预测它们擅长什么其实相当容易。不过我不太明白为什么它们在 UI 设计方面这么拉胯。
- noduerme
作为一个对加密技术一无所知的人，我唯一知道的就是，“自定义加密”这几个字让我吓得要死。
- superjose
我觉得这得看情况。
取决于软件演化的程度以及它将如何被使用。
我们之所以花了数年时间去发现模式、创造特殊的语法，是为了更高效地解决某些领域的问题，并构建能够随时间演化的系统。
唯一不变的就是变化本身。
尽管 LLM 能生成代码块（并且凭借深厚的知识储备输出令人惊叹的结果），但开发者必须拥有足够的知识储备来跨过某个门槛。
一开始用不熟悉的语言写代码似乎没问题。但一旦触及边界，你就会发现各种怪癖和效率低下的地方，而 LLM 可能会选择绕过这些问题，而不是从根源上解决它们。
例如，我最近几周一直在学习 Effect.ts。我大量使用了 LLM，但在此之前，我经历了一系列手动编码的轮次。
我需要理解组合性（composability）、细节之处、哪里会出问题、如何出问题、语法是如何构建的，以及我该如何围绕该库构建一些可观测性（observability）挑战的解决方案。
如果我没有经历这个过程，代码质量就会大打折扣。起初这可能不明显，但一旦系统开始演化并适应反馈，问题就会变得脆弱，现有客户会受到影响，等等。
我喜欢快速推进，但绝不搞砸事情。
- jbstack
> 有一件事很清楚：熟悉一门语言这一行为已不再重要
我完全不同意文章以此为前提。
当然，如果你完全不在乎代理生成的工作是否可靠，那确实没必要学习语言。但如果你是一位关心自己工作的开发者，而不是只产出 100% “凭感觉”代码的人，那么至少你应该对语言足够熟悉，能够审查代理的输出、跟上代码逻辑，并就是否提交代码做出明智的决定。
有趣的是，我发现我学习语言的方式发生了根本性的改变。以前，我会研读一两门当时对我很重要的语言的书籍，目标是精通它们。现在，我选择阅读各种语言，仅仅因为它们展示了我以前未接触过的有趣范式（例如：Haskell -> 函数式，Elixir -> 并发）。我读编程书就像读一本引人入胜的非虚构叙事作品：从头到尾快速读完，然后就结束了。这给了我一种对“代理式编程”有用的“熟悉感”，而无需去死记硬背每一个晦涩的语法细节或库调用。我的优先级已经从深度（把一两门语言学透）变成了广度（概览多种语言和范式）。