“我们最终将放弃 TypeScript 版本的 CLI，转而采用 Rust 版本。”
当 OpenAI 推出 Codex CLI 时，其目的是让开发人员能够使用熟悉的堆栈（基于 TypeScript 和 React 的 Ink）在终端中更轻松地与 AI 进行交互。
虽然它试图与 Claude Code 和类似的工具竞争，但团队还是决定改造其基础，以获得更好的性能。“我们一直在努力将 Codex CLI 重写为 Rust，”OpenAI 技术人员 Fouad Matin 在 GitHub 讨论帖中说道。
尽管 TypeScript 版本在快速原型设计方面非常高效，但随着 Codex CLI 在各种用例中逐渐成熟，它开始显露出其局限性。
现在，OpenAI 计划完全放弃 TypeScript CLI，转而采用 Rust。Matin 提到，TypeScript 版本目前仍将继续接受错误修复，重点是将原生 Rust 版本的功能与 TypeScript 版本保持一致，并最终将其作为默认版本。
Rust 的 4 大核心优势
虽然 Rust 有其自身的问题和优势，但这次转换并不是出于语言理念上的考虑。正如 Matin 所说：“我们希望使用最适合这项工作的工具。”Codex CLI 可能是在 React 上构建的“一个整洁的终端 UI”上推出的。
然而，他指出，从核心功能来看，CLI 作为一个循环运行的工具，需要持续与 AI 模型和系统交互，而非仅仅展示一个漂亮的终端界面。对于此类与本地系统资源和 API 的重复交互，TypeScript 开始显得力不从心。
“我们希望改进几个方面，”Matin 解释道。
首先，安装体验需要改进，因为当前版本“需要 Node v22+，这可能会让一些用户感到沮丧或阻碍他们使用”。其次，需要改进本机安全绑定。“自从绑定可用以来，我们已经为 Linux 沙盒提供了 Rust。”第三，重点放在运行时性能上。“没有运行时垃圾回收，因此内存消耗更低。”
除了性能之外，Rust 还提供了架构上的余地。Matin 表示，OpenAI 正在为 Codex CLI 开发一个“线协议”，该协议将使开发人员能够使用各种语言（如 TypeScript/JavaScript 和 Python）来扩展代理。Rust 已经支持 MCP。
换句话说，Codex CLI 不仅仅是一个工具，它旨在发展成为一个跨语言、易于插件的基于模型的自动化运行时。
正在开发中，但“非常流畅”
虽然新版本的 Rust 仍在开发中，但到目前为止，反响还是非常乐观的。一位开发人员报告说，“到目前为止，codex 本机非常流畅”，尽管 TypeScript 和本机版本之间仍然存在一些差异。这包括配置文件支持以及使用免费模式或使用 OpenAI 帐户登录的功能。
OpenAI 正系统性地解决这些差距。在另一个 GitHub 帖子中，OpenAI 技术团队成员 Michael Bolin 将剩余工作分为 P0（必须修复）、P1（功能一致性）和 P2（质量提升）三类。
原生 Rust 版本的高优先级功能包括“使用 ChatGPT 登录”和改进的中断处理。其他功能，如会话管理和提示建议，将在功能对等处理完成后推出。
“我们最终将放弃 TypeScript 版本的 CLI，转而采用 Rust 版本，”Bolin 在 GitHub 帖子中写道。该路线图反映了一种有条不紊的升级路径，而不是匆忙的重写。
原生开发成为新常态？
这一举措契合行业大趋势。在Hacker News上，有用户将其视为“近期工具回归原生开发浪潮”的一部分。
该用户解释说，JIT（即时）解释器越来越好，无需再使用本机语言的概念正面临越来越大的挑战。
与此同时，另一位用户指出，Rust 和 Go 使本机开发变得更加容易。该用户写道：“包管理更好，静态链接的本机二进制文件消除了许多部署难题。
借助 Rust，OpenAI 不仅改变了代码库，还改变了 Codex CLI 可以成为什么样的软件。从终端实用程序到可编程代理工具，CLI 的重建不仅是为了提高速度，还为了提高灵活性、可移植性和长期可维护性。
如果 TypeScript 版本是为 playground 部署的，那么 Rust 重写版本则计划用于现实世界。
最近原生工具的复兴确实令人感兴趣。多年来(至少过去十年)，我一直听到这样的论调：JIT/解释器已经变得如此强大，以至于无需再使用原生语言，客户端可以直接用Python/Ruby编写，因为这本就是一次性操作，等等，等等。
而现在，每个人都在用 Go/Rust 重写一切。
这实际上归结于 Go 和 Rust 生态系统易于使用。一二十年前，编写原生应用程序意味着要设置一个 automake/autoconf Rube Goldberg 机器——如果你需要为多个架构构建，这尤其困难。
我认为 Rust 和 Go 比 Python/JS/TS 更易于使用。包管理更完善，静态链接的本机二进制文件消除了许多部署难题。
从 Linux 交叉编译到 Mac，跨架构曾经是一项不可能完成的 bitbake 冒险。在 Go 中，只需两个环境变量即可完成！
附带一个重要注释：直到你需要使用CGO
最近我曾为一个未继续开发的副项目进行过类似的调查：难道不是只需传递CGO_LDFLAGS=—static并在musl上构建即可？
我认为在针对 macOS 时无法这样做
或 FreeBSD
正如你的兄弟们所说，但更普遍地说：基本上这只适用于 Linux。其他操作系统通常不允许这样做，你必须有某种程度的动态链接。
Go 曾经尝试过允许这样做，但由于引发了大量 bug，最终撤回了相关实现，据我所知。
公平。
作为接受过 BASIC 和 Z80 编程教育的人，这其实并不复杂，关键在于是否愿意学习。
有时人们真的需要遵循尤达和米亚吉的建议，而不是直接跳进去。
它确实很复杂。虽然不像量子物理学那么复杂，但仍然比必要复杂得多——尤其是如果你关心多种架构和平台。有一次，我正在为 Windows、MacOS、Linux(本身又细分为各种具有不同 glibc/openssl/其他版本的发行版)上的 X86、AMD64 和 Itanium 制作构建。维护构建管道的工作量比开发功能的工作量还要大。
Go 和 Rust 证明，您无需付出复杂性的代价，就能获得 C/C++ 的大部分优势。
嗯，Modula-2 和 Object Pascal 早在很久以前就证明了这一点，但它们没有花括号，也没有 UNIX。
两者都可以成立。它可以很容易学习，但也可能在为每个新项目和支持的架构菜单设置和调试时变得非常麻烦。
> 现在，每个人都在用 Go/Rust 重写一切。
对于 99.9% 的时间都在等待推理结果返回的软件来说，这尤其有趣。当然，重写那些严重依赖 CPU 的东西，或者你想更轻松地处理并发性的东西，这是有道理的，但我觉得这不是 Codex 完成提示需要很长时间的原因。
话虽如此，我也将我的本地大语言模型(LLM)代理软件重写为 Rust，因为与我的最初 Python 原型相比，它更易于处理并发。它编译成一个整洁的二进制文件是一个额外的好处，但用 Go 代替 Rust 也可以轻松实现。
> 对于 99.9% 的时间都在等待推理结果返回的软件来说，这尤其有趣。
在另一个领域，我看到一个用 Python 请求 oauth 令牌的 cli 工具被重写为 Rust，性能得到了巨大的提升。Rust 版本在几毫秒内就请求了令牌并将其返回给应用程序，但 Python 仅加载 OAuth 供应商推荐的模块就花了大约 5 秒钟。
这大大提高了性能，更不用说分发编译后的二进制文件要简单得多。
Python 的启动成本非常高。Node 也是如此。Go 非常不错，但 Rust 更出色。
即使像 Go 这样的 GC 语言在分配/释放内存方面非常快，但 Rust 从一开始就不需要分配/释放一定量的内存。程序员为编译器提供了优化内存管理的工具，而机器比人类更擅长优化内存。(至少某些类型的优化是这样。)
说实话，我仍然对 Go 程序的启动速度感到惊讶，尽管初始化函数中包含了大量内容，即使在标准库中也是如此(例如 Unicode 表等)
我花了一些时间优化 Python 在 Web 应用和命令行界面中的性能，确实糟糕透顶。
模块导入成本极其高昂，尽管在长期运行的应用程序中，你可以通过一些巧妙的方法将导入操作推迟到启动时间之后，因为Python具有高度的动态性，但对于那些不运行守护进程的一次性命令行操作，你根本无能为力。
我非常喜欢Python作为一门语言和一个生态系统，并认为它确实有其存在的价值……但这绝对不是在性能至关重要的领域。
EDIT：而且有一个可行的替代方案。Python 是机器学习语言。
打包 Python 应用程序简直是噩梦。npm 经常被批评，但 Python 同样值得被批评，甚至更甚。
我对 Python 打包了解得太多，而实际上只了解一点点。
我同意这确实是噩梦。但我尚未找到太多全面且不存在问题的打包解决方案。
依我之见，Python 打包社区已出色地开发了诸多工具，旨在简化打包流程，尤其是在使用 GitHub Actions 时。可参考：https://github.com/pypa/cibuildwheel
Pypa 提供了一系列适用于各种场景的 GitHub Actions 列表。
我认为大多数人最终陷入“纯粹地狱”是因为我们阅读了如何构建包的文档，而不是使用专家创建的工具来隐藏混乱。这有点像手动构建 deb 包比使用工具自动完成要困难得多。
这很公平。我也一直在思考利用 GPU 的 Python 应用程序的庞大体积。我猜想一个进行神经网络操作的 C++ 应用程序在下载权重之前体积不会超过 1GB。
我试过，仍然是几千兆字节，除非你尝试从 C++ 动态链接到用户安装的 CUDA 库。我不推荐这样做。
哎呀
说到这个，我不知道 Node 有一个内置的打包功能，可以将脚本转换为单个可执行文件：
https://nodejs.org/api/single-executable-applications.html
我之前也不知道这个功能，感谢提醒
我认为，对于Python和JavaScript等解释型语言，打包应用程序的有效负载就足够了
一切都遵循一个循环。客户端/服务器、扁平化/拟物化、编译型/解释型、云/数据中心、多彩/极简主义、微服务/单体架构、标准驱动/供应商驱动、开源/专有、CPU/xPU。技术世界中存在一种自然的张力，推动进步朝着一个方向发展，同时在另一个方向上积聚力量。随着时间的推移，你会看到这些循环的规律。
我迫不及待地想要“用 Rust 重写”的时代结束！
“用 Go 重写”结束得如此之快，真是疯狂。现在，所有那些原生的 Go 项目突然又变得不酷了。
官方的TypeScript编译器正在用Go重写。
啊，有趣
“现有的代码库做了一些假设——具体来说，它假设存在自动垃圾回收——这基本上限制了我们的选择。”
先等 Zig(及其生态系统)成熟吧。
这是下一个趋势。
感觉大的转变是 Rust 达到临界质量，以及大语言模型(LLM)辅助翻译使这些重写成为可能。Rust 是一种非常活跃的语言。
如果宣布 Codex CLI 将用 C++ 重写，可能会遭到困惑和嘲笑。
> Rust 是一种非常活跃的语言。
为什么你会特别说 Rust 呢？
与其他语言相比，Rust 程序一旦最终编译完成，就更可能正确无误，至少在避免意外运行时行为方面是这样。
如果你正确地构建类型并做好文档记录，就可以快速运行大量代码生成。
良好的错误信息对人类来说非常有用，对试图调试初始尝试的大语言模型(LLMs)来说也非常有用。
关于这个与之相反的说法：
https://news.ycombinator.com/item?id=44149809
你回复的评论是在谈论 Rust 编译器的错误。
你链接的评论是在谈论未指定的应用程序的运行时错误。
就我个人而言：其中一个原因是，这是大语言模型(LLMs)和 Codex 等工具最有用的一项功能。
当我有一个用一种语言编写的小型应用程序和测试时，让大语言模型(LLM)将这些文件转换成另一种语言是我最愿意几乎完全交由它来完成的任务。尤其是当我审查测试时，新语言中的所有测试都通过了。
我怀疑这些被称为“原生”的特性只是历史的偶然。Go 的优势在于它有谷歌的支持，而 Rust 只是一个设计良好的语言，恰好吸引了合适的社区。就我所见，所有认为原生特性没有必要的理由仍然成立。
然后他们基于 Electron 开发了一个图形用户界面。
需要注意的是，如果JIT语言是Java、C#、Common Lisp、Dart、Scheme或Raket，那么大多数这些重写都是不需要的。
而且，上述所有语言都具备AOT编译器和JIT缓存工具。
> 然后他们基于Electron开发了一个图形用户界面。
如果这种做法流行起来，越来越多的工具都采用“chatgpt、将其翻译成 Rust、使其运行起来”的方式，希望有人能投入时间和金钱，将 tauri 提升 10-20%，使其成为通用的 Electron 替代品。Tauri 非常棒，但仍然存在一些问题。
对于 cli，我确信 node 的最大缺点是缺乏可移植性，以及“可执行文件”占用的空间非常大。
我对这个决定的商业角度很感兴趣。你怎么说服你的老板花数百个工时来用 rust/go 重写 python/typescript/其他语言？
是什么因素能驱动投资回报率？
使用 NodeJS 等语言编写的大型 CLI 确实会明显感受到启动延迟。从 >100ms 到 ~0ms 的提升，对用户体验而言是巨大的改进。
这主要取决于你需要运行该命令的频率。
CLI 与其他软件不同，因为它们经常被启动和终止。
如果我们也能摆脱 React Native 就好了。
> 现在，每个人都在用 Go/Rust 重写一切。
这似乎是一种确认偏见。
Codex 与 Claude Code 相比糟糕透顶，尽管 Anthropic 的单个模型其实并不比 OpenAI 好多少。他们本应将此作为首要任务，而非进行重写，这只会让改进工作沦为次要。
使用Claude Code的经历糟糕透顶——它甚至无法通过现有代码的基本API测试，而Codex搭配o3一次就搞定了。
Claude Code倾向于编写毫无意义的测试只为通过——比如验证1+1=2——并认为这已完成任务。
如果 Codex 能够证明对 Rust 的重写是使用 Codex 本身而不是人工完成的，那岂不是一个很好的展示吗？
如果今天还做不到这一点，那么面临哪些挑战，人类需要介入并纠正模型的地方在哪里？
如果可以做到这一点，那么 OpenAI 将停止销售人工智能，转而开始销售服务。
过几年再看看吧。他们的盈利能力可能取决于这些服务的销售。唯一的问题是，卖哪一种呢？
随着 RIIR 进入 nodejs 生态系统，我正在等待博客文章，了解人们如何彻底摆脱 nodejs，用 Rust 重写整个后端，以及一切如何变得更好。
等待 Show HN：AbrasionNext，面向前端开发人员的框架演进，采用 SaaS 云部署。
似乎 Rust “只需要” RoR 级别的 Web 框架和 Qt 级别的 GUI 框架就能征服世界，其他的一切都已经征服了(只有一些 Go 教皇会议还在坚持)。
> Qt级别的图形用户界面框架
正在尝试通过Slint实现：https://slint.rs
> RoR级别的网络框架
这不会发生。新开发者已转向SPA/RSC，而RoR类型的框架在这种背景下并不合逻辑。
Elixir/Phoenix 表现非常出色
“似乎 Rust ‘只是’ 需要 RoR 级别的 Web 框架”
它已经出现了 https://loco.rs/
我正在用它编写一个生产级别的应用程序
> 我正在等待关于人们如何完全淘汰 Node.js、用 Rust 重写整个后端的博客文章
我已经在多个项目中这样做了，效果很好，成本和计算/内存使用量都大幅降低。
这是我见过的最荒谬的 RIIR 之一。
这是一个进行 API 调用的 CLI 工具。我敢打赌，在 Ruby/Python 与 Rust/C++ 等语言中，API 包装 CLI 工具的性能差异在感知体验中可以忽略不计。
如果他们希望人们不依赖预装的 Node，他们可以提供单一可执行应用程序的 [0] 或使用类似的工具来生成二进制文件。
或者使用Deno/Bun的原生二进制打包功能。
[0] – https://nodejs.org/api/single-executable-applications.html
CLI 工具具备自包含特性且易于交叉编译，这无疑是一大改进，二进制文件大小的优化同样显著(从我观察到的情况来看，封装的 Node 二进制文件体积庞大)。此外，CLI 工具应具备低延迟特性，无论引擎性能多么出色，解释器相较于真正的二进制文件仍会产生更高的启动延迟。
这不仅仅是 API 调用。
通常涉及 I/O(网络、文件系统)和计算任务(如测试和编译代码)的并行处理。
这些工具只是在 shell 中运行测试/编译命令……
这已经酝酿了一段时间(Rust 分支已经可以试用了)；据我理解，推动这一发展的动力只是为了在 Node 安装困难的地方安装 CLI。
我很好奇，有多少重写是使用 codex 本身完成的。这似乎是一个完美的用例。
我猜应该有相当多的部分。负责大部分 Rust 重写的维护者向我维护的 Ratatui 小部件库之一提交了一个 PR，该库似乎是由 Codex 产生的[1].
[1]: https://github.com/joshka/tui-markdown/pull/80
这正是我一直读到的内容的有趣证明。人们可以快速用AI生成一些东西，比如PR，但最后10%的工作却悬而未决。
如果Codex真如演示视频中所说的那样好，他们本可以在等公交时用手机向ChatGPT发送请求，它就能解决你的评论……
你所说的最后10%其实是些微不足道的小问题。这就像最后的0.000001%。而且，它本可以在一分钟内自行解决所有这些问题。
我的一些回应评论是挑剔的，因为该工具没有遵守代码中的惯例/引入了未使用的惯例。我希望，遵守现有惯例是基于大语言模型(LLM)的代码工具最终会明确纳入其上下文和防护栏的内容。直觉上，由于各种实际原因，这似乎很难在模型的训练中实现。
为什么没有这样做？
我猜要实现这一点需要运行Codex并确保特定仓库/PR上下文在范围之内。也许开发者还没做这件事？
这是一个有趣的问题。这些公司有多少代码是由他们出售的工具编写的？
我怀疑并不多，因为我从未看到这些公司发布过相关统计数据。
Aider确实公布了这些数据，而且非常有趣——https://aider.chat/HISTORY.html
> Aider编写了大部分自有代码，通常每个版本中约70-80%的新代码来自Aider。这些统计数据基于Aider仓库的Git提交历史。
> 每当 Aider 修改文件时，它都会以描述性提交信息提交这些更改。
有趣的模型。每次提示响应接受都会获得一个 Git 提交，且无需人工修改。
人们将语言选择与内存管理策略、编译机制、分发工具集和类型系统严格性混为一谈，这很有趣。我的意思是，一方面，人们解释说 Rust 的手动内存管理使其速度快，但另一方面，他们又称赞垃圾回收的 Go 速度快、启动延迟低。并不是手动=快，GC=慢：而是 Go 的 GC 并不差，你可以制作快速的 GC 程序和慢的手动内存管理程序(比如游戏及其臭名昭著的加载屏幕)。将 GC 与慢等同的观念只是行业意识中的一种简化想法。
同样，你可以很好地实现 TypeScript 程序的单文件分发。(Bun 甚至内置了支持。)但人们并不认为这是该生态系统中的“一件事”。这只是文化问题。TypeScript 意味着 npm 或 Electron。这是行业集体意识中嵌入的等价关系。
需要明确的是，我并非在谴责这种等价关系。简化是有益的。我们用语言作为一组选择的简写，这些选择并不一定与语言本身绑定。你可以用 Nuitka 编译 Python，甚至解释 C 语言。但为何要在技术变量的每个维度上独立选择，而不用一个已知良好的“预设”——即语言呢？
语言选择包中最重要且最被忽视的部分是开发者文化。当然，从理论上讲，语言选择应与思维方式、兴趣领域和能力类型无关。但让我们面对现实。事实并非如此。所有人类社区和Go开发者都会发展出共享的实践、仪式、口号和权威群体。开发者社区也不例外。
当你选择像Rust这样的语言时，你不仅仅是在选择一种编程语言。你是在选择那些喜欢使用这种语言的人所共同秉持的一套信念和实践。例如，Rust社区的人非常重视性能和安全性。TypeScript社区的人可能更关注开发速度。而C语言社区的人则更关心应用程序二进制接口(ABI)的稳定性，这一点比前两者都重要。
即使控制了人才水平，你也会得到不同的侧重点。Codex 社区的人正在制定一种自定义代理的线格式。C 语言开发者可能会通过创建插件系统来解决问题。TypeScript 开发者则会说，直接和他们沟通，他们能更快地提供你所需的功能，比你自己编写扩展更快。
有时甚至会看到多个实践者群体。游戏开发和高频交易可能使用相同的 C++ 语法，但我认为它们相差甚远，彼此之间的相似性不如 Java 和 C# 开发者之间那么高。
这就是为什么语言争论会如此激烈：它们不仅仅是在表达偏好。它们是在为自己的阵营而战。此外，没有什么比来自不同社区的人盗用他们的神圣语法并通过错误使用来玷污它更让语言社区感到愤怒的了。
Codex 并不是在交换语法，而是打赌 Rust 文化实践会在这项利基市场中胜过 TypeScript 文化实践。我非常期待看到这个自然实验的结果。
我喜欢这种对编程语言选择的民族志解读，认为它与文化和技术特征同样重要。我好奇大语言模型(LLM)编码代理会带来什么影响，因为它使语言之间的重大改写变得微不足道，并可能让开发人员快速在语言之间切换程序以获得优势。这让人想起右翼煽动的移民辩论。
许多人尚未完全意识到，当代理开始直接生成可执行文件时，他们钟爱的编程语言将变得无关紧要。
我们正处于编程范式转型的中间阶段。
让AI编程模型之间的争论开始吧。
编译器理应成为任何与计算相关的教学内容的一部分，以破除编程语言的都市传说。
遗憾的是，这只是一个永远无法实现的乌托邦。
人们将继续基于道听途说、随处找到的书籍、网红等学习编程语言。
如果我正在制定计算机科学课程大纲，我会将编写C解释器和Scheme编译器作为必修项目。
这听起来像是对开发者任性的事后合理化。话说回来，Node从一开始就是个奇怪的选择
我惊讶于性能没有被列入清单。我最初在JVM上启动Brokk的主要原因是访问https://github.com/joernio/joern，但能够轻松支持多核的高性能代码是一个非常不错的次要原因。
列表内容：
> 优化性能——无运行时垃圾回收，从而降低内存消耗
介绍列表(效率对我来说是性能的更具体形式)：
> 我们的目标是让软件组件尽可能高效，并且有几个领域我们希望改进：
gc 对大语言模型(LLM)代理的影响可以忽略不计。
其他方面(“零依赖”)实际上与效率无关。
将 GC 作为重点关注对象并非完全没有道理。但对我来说，这似乎有些过于关注了。
效率是最高层级的目标，它在大部分计算任务中直接等同于性能：更高效率意味着能够让其他工作得以进行。虽然有时单线程的纯粹速度更优，但通常在计算领域，我们尽可能在方法中引入并行或并发，以便效率能够直接转化为整体性能。
整体性能作为要点似乎足够清晰。虽然提到了GC，但我不认为团队愚蠢到认为GC是这里唯一可能获得的性能提升因素，即使他们没有列出其他因素。
即使是相当慷慨的解读，我也认为他们正在做被要求的事情。性能非常明确地存在，对我来说，我认为这是一个非常清晰的目标。
GC在异步流程中尤其不相关。我不知道他们优化的是什么……
我希望他们能优化ChatGPT桌面客户端。它在我这里经常卡顿。
听起来他们实际上是在转向闭源，并使用 Rust 重写作为掩护。
这很有意思，因为目前的 Codex 软件支持第三方模型提供商。对于 OpenAI Codex 来说，这是合情合理的，因为与 Claude Code 相比，它处于劣势，但也许他们已经改变了对此的立场。
[编辑] 看来这个版本有误；源代码在树中。
看起来是开源的 – https://github.com/openai/codex/tree/main/codex-rs
对于所有这些“人工智能是未来”的说法，OpenAI 的代码库中居然还存在“待办事项”注释，用于我能想象到的最简单的事情，这究竟是怎么回事？<https://github.com/openai/codex/blob/rust-v0.0.2505302325/co…> 文件顶部的一条评论更让人感到困惑，因为该评论阐明了这一要求，因此无需添加“？”。[https://github.com/openai/codex/blob/rust-v0.0.2505302325/co…](https://github.com/openai/codex/blob/rust-v0.0.2505302325/codex-rs/core/src/mcp_connection_manager.rs#L27)
我敢打赌，输入这条评论所花费的实际时间，比让任意数量的AI代理快速生成等效的
if not re.match(...): continue代码所需的时间还要长这似乎有些不近人情。
// TODO: 验证服务器名称：要求符合 `^[a-zA-Z0-9_-]+$`？服务器名称验证可能需要执行多个步骤。
该正则表达式并未涵盖服务器名称的所有可能形式。
作者显然决定暂不确保此低风险测试的正确性——待进一步思考、研究、咨询或更高优先级处理。
好，这是一个好兆头。我在Github线程中没有看到任何指向源代码的链接，该线程中唯一提及贡献的内容是一封申请工作的邮件。我不会删除我的评论，因为你展示的子树没有LICENSE文件，所以情况并不完全清楚，但我同意它至少似乎仍然是开源的。
审查该树的源代码，看起来它已经公开开发了一段时间，有很多PR。
事实上，情况非常明确。仓库根目录下确实存在LICENSE文件。添加一个新子树(目录)不应质疑该子树是否受现有许可证覆盖。这很荒谬。如果他们想更改许可证，就需要对许可证进行实际修改。
希望OpenAI能将Codex CLI作为订阅服务的一部分，而非按API定价。
人们会不惜一切代价来避免阅读和维护别人的代码。如果这意味着用本机语言重写，而且有人(通常是风险投资公司)为此买单，那就这样吧。如果你觉得在现有的 TS/JS 代码中工作很难，那就等着有人把 10 万多行的 Rust 代码交给你，让你进行更改吧。五年后，又会发生一次重写和更改一切的大转变。
对庞大的 Rust 项目进行更改非常容易。对于重大更改，你进行更改后，编译器会告诉你它引起的 100 个问题，然后你修复所有问题(大约 50% 自动修复，30% Claude/Codex，20% 手动)，然后程序可能就能正常运行了。
设计最初的10万行代码程序需要技巧，但这种努力主要集中在前期。
每个人都忽略了他们这样做的原因。这与帖子中的内容无关，也不是技术决策。
这是关闭Codex的一种方式。如果代码是类型脚本，那么制作封闭源代码就没有意义了。但如果是 Rust，那就另当别论了。
这只是让 OpenAI 变得不那么开放的又一举措。
想象一下，首先用 JS 编写一个 CLI…
现在正在等待 Claude Code 用 Rust 重写。
他们正在将 Codex CLI 从 TypeScript 重写为 Rust，以实现性能、安全性、零依赖安装和可扩展性。
这样能获得什么样的性能提升？在我看来，99.9% 的计算都是远程进行的。
可能提升有限，主要是因为无需启动独立的V8引擎及其垃圾回收机制，就像Electron应用需要启动独立的浏览器引擎一样。但从CPU角度看，客户端并未进行任何复杂操作。
对我来说，最方便的是无需配置Node环境。只需复制原生二进制文件即可直接运行。
有各种解决方案可以将节点程序转换为独立的二进制文件，方法是将节点或多或少地包含在二进制文件中。我之前成功使用过的一个解决方案是“pkg”。
我更希望不必为了运行一个程序而打包整个语言的运行时，因此 Rust 是很好的选择。
无需等待 2 秒钟让运行时启动。
是的，他们可能可以用 Go 语言实现这一点。
当然，这两种语言都同样适合此类任务。
如果您正在解析 JSON 或其他序列化格式，我认为这可能并不简单。是的，这主要由 LLM 调用主导，但序列化本身是纯 CPU 操作。
此外，理想情况下，你的轻量级客户端逻辑可以在内存使用受限的小型设备/服务器上运行。如果 OpenAI 为每个 Codex 查询启动一个服务器，那么服务器的大小(在规模和成本方面)就很重要，因此减少几兆字节的开销是值得的。
可能占用更少的内存？
最大的问题是没有将 Node 作为依赖项。性能、可扩展性、安全性，这些都不太值得重新编写。
我明白 OpenAI 为什么没有投入时间和金钱来做这件事，但我很好奇为什么没有人写一个 JavaScript 前端来支持 LLVM。
应该没有理由不能这样做，而且这样可以提高性能，并且无需依赖任何安装。
“LLVM 的 JavaScript 前端”是什么意思？
编辑：啊，我明白了，我一开始把 LLVM 读成了“LLM”！直到我发布问题后才意识到自己的错误。
我不确定将 JavaScript 原生编译是否有意义，因为该语言的动态特性会导致实现速度非常慢(JIT 编译器会通过假设来优化代码，当假设不成立时会回退到较慢的基线，但 AoT 无法做到这一点)。
> 我不确定将 JavaScript 原生编译是否有意义，因为该语言具有高度动态的特性
这是一个很好的观点，也许 TypeScript 会是更好的选择。
TypeScript 与 JavaScript 同样动态。
要将 TS 编译为原生代码所需的努力，可以参考 AssemblyScript。
> 但我好奇是否有人写过 LLVM 的 JavaScript 前端
Astral 团队正在记录。我不会惊讶于他们已经有一个超级机密的分支，在那里他们重写 Python 并使其速度提升 100 倍，但没有像 Mojo 这样的 AI 垃圾。
感谢。不清楚“转为原生”具体指什么。
理由太牵强了，简直就是因为我想用 Rust 重写而已。
显然，安装 Node 对一些客户来说是一个障碍。这并不让我感到惊讶。如果这能阻止一个中型企业客户，那么重写是值得的。
这对许多Windows企业客户来说是个障碍。建议使用nvm来管理(链接：https://learn.microsoft.com/en-us/windows/dev-environment/ja…)。
这需要管理员权限，这意味着需要向IT部门提交工单，而且很可能被拒绝，因为这会打开一扇大门，允许安装许多IT无法控制的管理员级软件。
在WSL下安装Node.js是一个更好的方法，但这会让企业客户更加困难。
它可以是一个解压后设置 PATH 的 ZIP 文件。
https://nodejs.org/en/download
我从未使用过 nvm。
如果有人不明白这一点，那是个技能问题。
我基本上避开了整个 TypeScript/JavaScript 生态系统，因为我不想处理 Node 或其生态系统。Yarn、npm、npx，然后是构建系统 Gulp、Grunt、Webpack 等，感觉非常令人困惑。
是的，如果我花更多时间学习这些东西，它们会变得简单，但那似乎是巨大的时间浪费。
Node.js的安装有时确实很麻烦。Node.js生态系统多年来一直存在多个与安全相关的问题。供应链攻击是我主要担忧之一。
我认为大多数包管理系统，如果还没有的话，将开始面临真正的供应链攻击。从攻击者的角度来看，Node.js 生态系统中存在大量缺乏安全意识的用户，这为攻击提供了更好的温床。
这不是一个合理的理由吗？
这只是浪费时间。JavaScript 是目前最自然的计算机语言。
他们已经没有真正有用的东西可卖了吧？大语言模型(LLMs) 没有商业价值(任何价值都因不确定性而抵消)。
> 大语言模型(LLMs) 没有商业价值(任何价值都因不确定性而抵消)。
有趣的观点。
我认为你指出了使用大语言模型(LLMs)的真正工程挑战——克服不确定性。在某些情况下，合理程度的不确定性是可以接受的，因为该工具本身是由专家使用的(即编码工具)，但在其他情况下，你需要设计更多的防护措施，以确保结果达到足够的质量。
> ？大语言模型(LLMs) 提供 0 商业价值
使用情况取决于用户，我明白了。
天啊，这个网站太糟糕了。它会劫持你的浏览器历史记录，导致你点击返回按钮时会被困在他们那个糟糕的AI网络研讨会的广告中：
(function() { if (window.history && window.history.pushState) { window.history.pushState(null, null, window.location.href); window.onpopstate = function() { window.location.href = “/aimbrandsolution/”; } ; } } )();编辑：现在跳转到他们的主页，但还是什么鬼？
我们本不该给程序化访问历史记录的权限。
这感觉像是重大安全问题
等你看完其他未经信任的JS能干的破事就知道了…
比如什么？
读取和写入剪贴板。
你以为你复制了一段 Bash 代码片段，但粘贴时却是另一段内容。
剪贴板至少需要权限。
我认为在 Firefox 中无法读取你的剪贴板。如果网站尝试读取，会弹出一个“粘贴”按钮，你需要点击它。
不，那不正确。你需要授予权限，而且仅在安全上下文中有效。
什么不正确？点击按钮可以写入剪贴板。
是的，但你不能在没有粘贴事件和用户权限的情况下读取非同源内容。
它会弹出一个包含“粘贴”选项的单元素上下文菜单。我猜这样可以吧？
99.99%的人永远不会运行Bash命令，所以问题不大。
作为那0.01%，我们同意在执行来自随机来源的命令前先进行验证。
从技术上讲，每次使用闭源软件时，你都在执行无法验证的随机来源代码
错误很容易发生，因为终端中的粘贴操作可能立即执行。
我不确定bash的情况，但zsh对此有安全措施，可以检测历史记录
我的意思是，他们不需要将任何内容注入历史记录就能让你跳转到其他页面，他们可以直接将你重定向到那里。
或者窃取表单输入、密码、泄露你的数据、破坏你的资源、以你的名义提交内容……
我之前甚至没考虑过这一点。就我所知，你可以检查引用者并当用户尝试返回时显示相应的钓鱼页面。好奇还有哪些其他类型的攻击是可能的。
不过，在历史 API 出现之前，通过程序化修改 URL 哈希值也可能实现类似效果。浏览器会保持在当前页面，但将其视为不同的历史记录条目。
还可以设置 opener.href。但我不确定他们是否移除了这一功能？
我刚刚查阅了 MDN(https://developer.mozilla.org/en-US/docs/Web/API/Window/opener)，发现其限制比我预期的要宽松得多。关键是，除非指定了`noopener`，否则`location`属性在跨域情况下仍然可用：
什么？
其实不然。页面无法访问来自不同域的其他网站的历史记录，因此在这一方面同源策略得到了遵守。如另一条评论所说，你可以使用 pushState 推送一个钓鱼页面，但这种攻击向量似乎极其不可能——毕竟用户已经访问了你的页面，为什么不直接让该页面看起来像钓鱼页面呢。
我觉得关于钓鱼攻击预防的信息总是“检查你点击的链接，确保它是正确的网站！”所以如果用户返回，他们的脑子会绕过这个心理检查，因为他们相信浏览器会回到他们来时的真实版本。这是一种额外的社会工程学，我猜。
这完全不是问题。这让单页应用(SPA)变得可用。
我访问的很多网站都会把你困在其中，而且后退按钮无法使用……
那不一样。那只是一个重定向。当你点击后退时，它会再次触发相同的重定向。与向JavaScript提供浏览器历史记录无关
今天学到的新知识，谢谢
没有它，SPAs就无法正常工作。
错误在于提供了对之前历史记录的程序化访问。网站没有理由能够与在访问该网站之前的历史记录进行交互。
单页应用程序本身就是个错误。
好消息是它们做不到。
那个网站就是个毒瘤。我深有体会，因为我就是个毒瘤。
这种情况让我养成了对每个链接都用中键点击的习惯
在另一个新闻网站上也看到过类似的情况，当试图返回时，他们会显示“你可能还喜欢”的新文章
看起来它们都使用了同一家公司或平台(IGN、Toms Hardware等，非常令人沮丧)
当 OpenAI 说他们要使用 Rust 时，我没想到他们是认真的！
我以为在承诺的乌托邦世界里，这类问题不会存在。毕竟，代码是为人类而写的，不是为机器人。
谁说代码不是为机器人准备的？
只要是反大语言模型(LLM)的，胡说八道也能得到赞。
反大语言模型(LLM)很容易，因为它是一个垃圾工具，带来的问题比预期的要多。
抱歉打断一下，但根据经验，随意使用垃圾大语言模型(免费/廉价订阅)会制造出垃圾(=垃圾提示)。升级并仔细设计提示会带来令人惊叹的结果。现在，它最终会带来更多问题，因为……代码越多，问题越多，这是软件的终极真理。
只有当你出于某种原因认为它是一种灵丹妙药时，才会产生比预期更多的问题。
我的意思是，你使用“比预期”这个词，某种程度上暗示了问题在于你的期望，对吗？你的期望太高了，现在却把责任归咎于大语言模型(LLMs)的存在。
但再次重申——你只是在重复同样的模式。只要是反人工智能的，那些毫无意义的胡言乱语就会得到赞同。你可以尽情讨厌大语言模型(LLMs)，但它们确实是令人惊叹的技术。
当然，关于人工智能的所有炒作与人们的期望无关。完全无关。
是的，显然是这样——但如果你要评估某件事物的有用性，你不应该尽量保持客观，不要被炒作所蒙蔽吗？
如果你相信了炒作，那么你就是犯错的人。你就是被欺骗的人。在我看来，大语言模型(LLMs)作为一项技术，与炒作并存，你应该尝试客观地评估它们。
遗憾的是，我不是高级管理人员，而他们很容易被营销的华丽辞藻所蒙蔽。
我们都应该憎恨那些加剧气候危机的工具。AGI不会是人类的终结，气候变化才会，而且要逆转少数人因缺乏远见和思考而对世界造成的破坏，可能需要数万年时间。
所有工具都会加剧二氧化碳排放。计算机、汽车、农业、制造业。你购买和消费的每一件产品都会这样做。
讽刺的是，你正在使用一台由电力驱动的计算机打字，通过由电力驱动的互联网传输你的信息，而这些信息存储和传输在由电力驱动的服务器上。所有这些都是使用需要电力生产的材料建造的。
所以你是一个巨大的伪君子。
我的意思是，与其否认问题存在，不如承认自己是个伪君子。我们应该减少汽车数量、减少制造、减少肉类消费等等，而不应通过扩大那些加剧现有问题的技术来火上浇油。问题不在于技术本身，而在于盲目扩张。
不，问题在于二氧化碳排放，而非所有生产活动。清洁能源才是解决方案，而非缩减经济规模。
错误。问题正是技术本身，尤其是产生二氧化碳的技术，这是唯一的问题。
自愿缩减经济规模永远不会发生，人们宁愿让地球变暖也不愿降低生活质量。选择只有两个：清洁增长/扩张，或崩溃。
那么这与大语言模型(LLMs)有什么关系呢？
大语言模型(LLMs)使用能源——实际上一切事物都使用能源。
老实说，我觉得有趣的是，在能源使用方面，更多的人并不反对游戏。我猜想，游戏消耗了大量能源。所有那些 GPU、互联网连接等等。
大多数消耗能源的事物都有预期效益，因此你可以进行有根据的分析，权衡利弊，并为你的具体应用场景选择一个最优平衡点。AI目前仍未以“效率”为目标，因为模型规模年复一年地扩大，但人们对AI未来可能达到的高度抱有过分乐观的期待，认为只要不断投入更多资源开发更大规模的模型，并祈祷其扩展曲线是指数级的而非S形的。
其他技术会随着时间的推移优化效率，调整到适合特定任务的合适规模。对于每个将设备性能推至极限的高端玩家，都有大量用户在便携设备上游戏，他们更关心电池续航时间，或是使用十年前的旧系统，这些系统本就无法运行高端游戏。人们不会炫耀效率，因此你看到的内容难免存在偏颇。
超大规模数据中心比普通数据中心差远了。
别怪我，而是要怪那些认为吸光所有能源和芯片、抱有“越大越好”心态的人，正是他们让事情变得极其困难，同时却赚得盆满钵满，坑害了数十亿人。
引用我之前在其他地方发表的评论：
我宁愿不成为新殖民主义的拥护者。不，谢谢。
如果要说有什么好处的话，超大规模数据中心由于规模经济，比“普通”数据中心更好。
我不知道你从哪里得到这种想法，认为我只在批评“普通”数据中心。我提到的所有内容(除了你自己的个人电脑)同样在超大规模数据中心上运行。互联网、Reddit等。快速搜索显示Reddit使用AWS和GCP。这些都托管在“超大规模数据中心”上。
感谢你让我们知道你是个白痴。
这是你的看法，伙计
我很高兴像你这样的短视的“缩减增长”白痴最终总是会失败。任何拥抱倒退式缩减胡说八道(就像你在推销的那种)的实体/公司/国家，最终都将被那些“越大越好”的人超越，迟早而已。人工智能已经到来，你未来也必须使用它，无论你喜欢与否。;) 除非你想去森林里生活。继续生气吧。
[deleted]
这是对人工智能宣传浪潮的反噬。你为某件事制造的炒作越多，它受到的反噬就越大。
我认为改变人们观念的责任在于人工智能宣传者自己，但就像加密货币爱好者一样，他们喜欢对信徒布道。
哇
虽然我是 Rust 的忠实粉丝，但我并不确定自己是否理解它的优势。
GitHub 上的原始讨论提到了以下原因
我开始阅读这个帖子时，对“用 Rust 重写”的决定持怀疑态度——我认为 Node 对于 CLI 来说已经足够好了——但这是一份非常好的优势列表。我想我最好继续学习这门语言，因为它似乎正在无处不在地占领市场。
至少它正在占领大多数 CLI 应用程序。
关于“用 Rust 重写！”的梗很多，但几乎每个这样做的项目都有很好的理由。
对于C/C++代码库：其中最重要的是能够吸引新的贡献者
哦，是的，是的！在软件圈中，软件的社交方面被严重低估：是否有足够的人愿意参与其中？
我猜大多数使用该API的用户都已安装了Node，而且这只是一个非常小的依赖项。
安全…绑定？什么？
没有垃圾回收并不意味着内存使用更少——你可以让一个Node应用程序使用不到1MB的内存。
我不确定Rust在实现任何协议时是必要的。
Node 并不是一个微小的依赖项，哈哈。并不是每个人都使用 Node。这种“现代”生态系统就是为什么一个计算器应用程序现在可能需要 1GB 内存的原因。
当然，我从未说过每个人都使用 Node。但许多开发者出于其他原因或使用 CLI 工具而安装了 Python 或 Node。
没错，但这与将其作为依赖项要求是不同的。假设最小的依赖并尽可能让工具无依赖是良好的软件工程实践。“许多”仍然意味着很多开发者没有安装 Node。
而且即使他们安装了，也不保证是同一版本。我觉得对于 Node 和 Python，安装方式有太多可能性，仅仅安装好只是第一步。第二步是弄清楚如何调用正确版本，而这本身就很麻烦。让你的工具成为依赖项可以节省大量工作、文档和客户支持工作，因为你的工具现在只需正常运行即可。
而且他们并不被迫使用石器时代的技术，也不必用原始汇编语言编写代码，因此这种权衡对他们来说并不算太糟糕。
这是一款开发工具。他们本可以同样轻松地提供一个使用 Node、Bun 或 Deno 作为运行时的单一可执行文件。而且我不知道有谁会使用这个 CLI 却没有安装 Node(或 Python/pip)。版本也不必完全一致——Node 的主要版本差异并不大，你可以针对 Node 12 进行开发，而它在 Node 24 上也能正常运行。
我并不是说 Rust 是一个错误的选择(它确实是一种非常棒的语言，可以用来制作 CLI 工具，还有许多很棒的库可以使用 cargo 导入)，我只是不认同他们重写它的理由(我认为，如果只是说“我们正在努力熟悉 Rust，并且总体上更喜欢它”，会更好)。
并非所有人都从事网页开发。即使从事，也不一定使用 Node。我认为如果你的圈子只做与 Node 相关的事情，可能很难想象，但软件工程是一个广阔的世界。
在我十多年的职业生涯中，我从未为工作写过一行 Node 代码。而且我曾转换过不同的领域。我只在家里的电脑上安装了 Node，因为有时我想玩玩它。
命令行界面(CLI)可能并不复杂，我怀疑重写所带来的成本并不显著。短期痛苦与长期舒适的权衡或许使其值得一试。如果发现了问题，不如尽早解决。
有很多使用Node或Python的CLI工具与网页开发无关。你不需要编写JS就能从这些工具中受益。
但耸肩，反正最后也没关系。
来自 GitHub 讨论：https://github.com/openai/codex/discussions/1174#discussioncomment-13335645
这与使用特定权限对子进程进行沙箱化相关
这听起来像是噱头，但嗯，OpenAI 就是这样吧。我猜这很容易被突破，而且他们依赖的工具是苹果正在移除的。真是不可思议。
这三点都是优点，但编译成二进制文件是个巨大优势。在运行应用程序前需要在环境中安装运行时库，这是一种值得避免的麻烦。
在某些环境中，由已知解释器解析的文本文件是个优势。
Bun 和 Deno 允许你编译为二进制文件
通过将整个 JS 运行时与二进制文件打包在一起。因此，如果你在机器上安装了十几个基于 Deno 的命令行工具，你也安装了十几个 V8 实例。
58MB 这是一个“Hello World”二进制文件(这是在他们将文件大小从100多MB压缩后的结果)。我猜现代存储技术让人们不再关心这些问题，但这感觉不对
Go 二进制文件也很庞大，因为谷歌会静态链接所有内容，但大家都告诉我不用在意。但我年纪大了，我将继续对着天空挥拳抗议。
为了对比，Go 的 Hello World 程序大小约为 2MB，大约是 Deno Hello World 程序大小的 3%。而 Rust 默认也采用静态链接，其大小约为 230kB，约为 Deno Hello World 程序大小的 0.5%。因此，也许你挥舞拳头的力量需要相应地调整一下。
此外，“Hello World”的比较可以让你很好地了解二进制文件的最小大小，但无法了解二进制文件的大小与工作量之间的比例关系，而这可能是更重要的指标。
Rust 默认情况下只在 musl 上进行静态链接。当与 glibc 链接时，它会进行动态链接。
顺便说一下，使用
tinygo的 Hello World 仅有 240k。我认为即使使用普通 Go，通过调整编译器参数也能获得更小的二进制文件，如果这符合你的需求的话。
在 Rust 中也可以这样做；这里有一个 2MB 的 http 服务器 https://markaicode.com/binary-size-optimization-techniques/
即使在2025年，100MB也微不足道。你可以将整个程序缓存在内存中，甚至无需触及现代机器上那浩瀚的内存资源。
事实上，你已经在这么做了。当你运行一个程序时，所有链接的库也会被加载。你的二进制文件可能只有30KB，但你同时加载了数MB的库来支持它。你节省的磁盘空间微乎其微，仅此而已。
100MB 用于一个“Hello World”程序
天啊，到了那个地步，你干脆直接虚拟化算了。
你忽略了关键点：共享库是“共享”的，因此无论有多少程序使用它，都不会占用更多磁盘或内存空间。
对于桌面和服务器而言，你的观点没错，也不该遭到负面评价，但在运行Linux的物联网设备(如树莓派)上，这仍占用相当大的内存空间。
100MB可能看起来不多。
但当你需要向所有用户推送更新时，情况就不同了。100MB还意味着大量传递依赖项，每个依赖项都可能包含安全关键补丁，这意味着你将面临几乎持续不断的更新需求。因此，实际更新开销将呈多项式增长，而非随文件大小线性增长。
你可以轻松地只打补丁到二进制文件的代码段
人们已经将完整的 Python 解释器内置到应用程序中长达约 20 年，而且很少有人抱怨。
这与 Electron 不同。
鉴于 Electron 应用的普遍性，我认为行业实际上并不在意存储空间。如果他们真的在意，我们会看到更多 WebView/Neutralino/Tauri 的采用。
但在这里看到 OpenAI 至少在一定程度上在意存储空间，这很好。
如果这是他们的意图，他们肯定会提到这一点，而不是一再强调性能。正如最初指出的，Node和TypeScript不会成为这个CLI的性能瓶颈。
人们一直在抱怨Electron。
至少Electron应用程序有其存在的理由(制作图形用户界面应用程序很困难)，但CLI应用程序并不需要如此笨重的运行时环境。
Node与SEA也是如此。
可以将JS编译为独立可执行文件。
deno 和 node 都支持——在幕后，它们是与您的应用程序代码一起精简的运行时，但这并不比编译和运行一个 rust 二进制文件更复杂。
参见：https://nodejs.org/api/single-executable-applications.html
https://docs.deno.com/runtime/reference/cli/compile/
虽然不复杂，但应用程序体积过大，且伴随自身安全问题并需要更多维护。
换句话说，使用类型脚本与 Rust 相比有什么好处？
有哪些安全问题是其他静态编译语言所没有的？
团队可以快速、轻松地迭代 typescript 应用程序。从项目速度的角度来看，我认为 TS 会更快。
诚然，我还没有深入研究过 Rust，但我听说编译器可以轻松地安全地进行全面重构，但我确信，对于一个新接触 rust 的团队来说，需要一些时间来适应。
编辑：我并不是说团队选择迁移到 Rust 是错误的！我认为对于此类项目而言，这完全不是一个坏主意。我只是指出，在 JS 领域，你可以编译和发布单个可执行文件。
坦白说，如果一个团队在TS和Rust方面的经验相当，那么项目的开发速度应该差不多，甚至在Rust上可能会更快，因为你默认可以避免更多潜在的陷阱。学习Rust其实并不需要太长时间，它拥有现代化的语法，而唯一的障碍可能是借用检查器，如果你之前没有使用过需要严格管理内存的语言的话。
太好了，谢谢你的观点。
我一直想深入学习 Rust……我目前从事网络服务工作(因此接触了很多 TS、python 等)，但也有相当多的 C + 内存管理经验。
我会把它放在我的清单上 🙂
在移植/重写项目中，这个问题不太明显，因为你已经对问题空间有了充分的探索。不过，你的观点对于新项目来说确实成立。
来自一家致力于开发工具以避免开发人员过多参与代码本身的公司，这应该不会成为他们的担忧。对吗？对吗？
使用 Rust 工作非常棒，但除非你对 Rust 有丰富的经验，否则你将花费大量时间搜索语法，并弄清楚如何使用借用检查器和其他语言功能。
我从未觉得自己能够用 Rust 快速编写代码来测试一个想法，我总是先坐下来用纸笔设计几个小时，然后才开始实施，结果发现除了 M 和 N 之外，我还需要 X 和 Y，现在我必须去设计它们。
有时我需要能够编写糟糕的代码。这并不是说糟糕的代码本身有什么问题，也不是说我打算将它投入生产，而是它可以帮助我通过分解来思考如何做某件事。我的一个个人项目是为 waveshare eInk 显示屏编写 TTY 驱动程序。我尽力用 Rust 编写它，但编写一个糟糕的版本然后进行迭代太难了。我必须同时理解整个项目，才能准确掌握内存使用模式。C 让我搞砸了。我遇到了错误，遇到了奇怪的故障模式……但我并没有被编译器错误所困住。在项目的第一天，我就看到了小屏幕上的文字。如果使用 Rust，我可能需要两到三周才能做到这一点。
不过，这纯粹是一个技能问题。我用 C 语言会苦苦挣扎数周，但用 Rust 语言却能在一两天内写出可运行的代码。
安装运行时其实并不那么麻烦。特别是对于 CLI 工具而言。老实说，分发二进制文件更麻烦，因为你需要操作系统和架构特定的二进制文件。
你不能真的将这两者相提并论？痛点完全不同：分发二进制文件是开发者的责任，而安装运行时是用户的责任。而且为一个 CLI 工具安装运行时绝对是过度设计。为什么我需要为一个在控制台显示文本的软件启动整个虚拟机？这听起来荒谬且 notoriously 臃肿，我讨厌它，大多数用户也讨厌它。
大量CLI工具都依赖于pip和npm。我不知道有谁会使用OAI CLI却没有安装其中任何一个。
你安装的是哪些运行时？即使是二进制文件，也需要根据平台安装运行时。在Windows上，你已经为各种程序安装了大量VC++运行时。分发二进制文件几乎就是Java和Python被设计成现在这样的一大原因。我确实分发二进制文件，但这确实很烦人。
在这种特定情况下，你必须安装Node.js。虽然JavaScript正在席卷世界，但仍有部分开发者不使用Node.js。因此，在他们的机器上安装Node.js来运行一个CLI应用程序显得有些多余。
我不明白分发二进制文件比分发一堆脚本文件更麻烦的地方在哪里。Rust 和 Go 支持自包含二进制文件，许多 CLI 应用程序并不需要外部依赖项。它们还支持交叉编译。为 Linux、Windows 和 Mac 编译，然后分发一个可以正常运行的二进制文件。没有比这更简单的事情了。
你是否完全错过了重点，即在以传统方式分发二进制文件与共享依赖于运行时/虚拟机的包之间，责任从开发者转移到了用户？分发垃圾显然对你更方便，但对需要接收它的人来说却不方便。这是同样的原理。人们不希望为了运行一个小型命令行工具而拖着一个庞大的运行时环境。我也不喜欢VC++的混乱，但你表达信息的方式几乎让人觉得这是唯一的选择。有一些语言拥有相对较小的运行时环境，可以构建为完全功能的独立应用程序，而不会占用任何资源，绝对不会像拖入整个Node/JVM/.NET那样。文章中提到了 Rust，它是一种运行时非常小的语言，许多开发人员(简单来说)认为它“没有运行时”，因为它的大小几乎达到了实际可接受的极限。
**就做一个该死的 .EXE 文件给我吧。
我他妈的不关心代码！我只想下载这个该死的应用程序并使用它
为什么要有代码？？？直接给我一个可执行文件就行了。这些白痴以为每个人都是开发者，都懂代码。而我不是，我也不懂。我只知道如何下载和安装应用程序。那么为什么他妈的有代码？制作一个EXE文件并给我。该死的臭烘烘的书呆子
你能指给我看在玩偶上代码触碰过的地方吗？
我不知道，问https://www.reddit.com/r/github/comments/1at9br4/i_am_new_to_github_and_i_have_lots_to_say/
你需要针对操作系统和架构的特定二进制文件来运行时本身，那么有什么区别？
对于 C 和 C++，你只需静态链接到旧版本的 glibc、musl 或 MSVC CRT，具体取决于你正在开发的平台。在 MacOS 上，你可以使用
lipo工具生成适用于 Intel 和 Apple Silicon 的通用(合并)二进制文件。这并不糟糕。一旦你设置好你的 Makefile 或 CMake，你就可以将其用作模板。这是困难的方法。Rust 和 Go 构建系统使操作变得更加简单。
Rust 拥有非常出色的 cli 库，例如 clap，它允许您以声明性方式定义命令行参数，还有许多 UI 框架可供选择。
还有一些不错的框架用于构建代理，如rig，以及与OpenAI集成的良好库。
它还拥有Anthropic提供的官方SDK以支持MCP(目前Go语言版本正在开发中，但尚未发布)。
但更重要的是，Cargo使得针对小型、无依赖的二进制文件进行构建变得非常简单，几乎适用于任何操作系统。
Typescript 有许多运行时依赖项，必须使用 npx 下载，而生成单个二进制文件的解决方案并不一定没有动态依赖项。
使用 Rust，您可以制作一个非常小的(3-4mb)二进制文件，该文件可以开箱即用(musl 和静态链接)，并且针对各种操作系统和架构。
我的团队为代码库 CLI 做出了贡献，并构建了我们自己的基于 Rust 的 CLI，因此我对它非常熟悉。
亚马逊的 q-cli 是他们自己的 Claude/Codex 版本，也是用 Rust 构建的。
生产力和便利性是选择 Rust 的主要原因。
嗯，没有 Typescript CLI 应用程序会在构建时随附 Typescript。
作为一名底层开发者，我一直困扰于如今性能似乎只是事后考虑。物理学家、工程师、开发者都在努力突破物理极限，从硅片中榨取更多性能，而开发者却像……嗯，我的文本编辑器就是一个网页浏览器。
软件本身的低效可能并不严重，但一旦加上其他所有软件的低效，你就会发现自己不得不升级硬件，而这些硬件本应足以应对。
不过我认为这有另一种观点。尤其在Linux爱好者中，这种对效率的追求显得有些无意义，比如他们会用一个声称只占用单核0.2%资源的程序，替换掉原本占用0.3%资源的控制台应用。
我理解这种动力，我自己也经常屈服于它，但我认为到了某个阶段，更值得探讨的问题应该是“如何以有益的方式利用我所拥有的额外计算能力”，而不是“如何在使用更少资源的情况下继续做和以前一模一样的事情”。
确实，但在这种特定情况下，我认为我们应该明确一点：对于这个特定应用，大约100%的能量和CPU/GPU时间都将由OpenAI一方消耗，而CLI在最终性能剖析中将不可见。
作为一个不久前还在优化一团糟的C++和JavaScript代码以实现16帧每秒的人，我这么说 🙂
正确性。使用一组极其严格的类型来开发系统要容易得多。虽然 TypeScript 支持可空类型，但它只是对 JavaScript 的补丁，且在运行时并不强制执行。
虽然正确性很重要，但严格模式下的 TypeScript 已经远远超过了 ML 家族以外的所有语言。我总是很乐意使用 Rust(或 OCaml、Haskell)，但 TypeScript 已经非常接近了，我认为对于大多数开发人员来说，这种差异并不重要。
当然，这并不一定适用于所有 TS 库。
当你的整个应用程序都是用 TS 编写时，运行时强制执行完全无关紧要。
我认为他们这样做只是因为他们有资源这样做。
如果他们可以同时使用两种语言，那么还不如使用 Rust。即使好处很小。
Rust 有很棒的 CLI 库，对于这种用例来说更易于使用。
内存使用情况可能是，大量的大字符串被发送，同时还要进行处理。
Rust 还有一个非常强大的生态系统，用于构建 CLI 应用程序(不过 TypeScript 也是如此)。
对于代理工作负载来说，这可能也非常相关，尤其是如果他们计划加入一些轻量级的大语言模型(LLM)来帮助 RAG 或长期记忆的话。
也许他们正在寻求扩展功能，但没有明确的路线图，很难说清楚。
如果你告诉我克劳德代码使用了 4GB 的 RAM，我不会在乎，因为这些工具的性能远超 500MB 的 RAM。
如果他们改用 Rust，你为什么会在乎呢？
因为这很可能是在浪费时间。现在，他们正在从代理功能中抽调工程时间来重写代码。
在分发 cli 时，你不会想捆绑一个 JS 运行时。
TypeScript 本身就很糟糕。似乎只有 .NET 开发者喜欢它。
它比直接使用 JavaScript 还要糟糕……
这是感知而非现实。TypeScript 代码库的 bug 并不少，但开发周期更长。
C# 和 TypeScript 相比，有什么地方更好？请指教 🙏
选一个？通常 C# 只在企业中使用，因为它(有意为之)的 Java 式设计和良好的标准库。它也因某种原因在欧洲地区备受青睐。
YMMV
我内心是一个 Rust 开发人员(之前是 OCaml 和 C++ 开发人员)，但我认为 TypeScript 是一个相当不错的语言。
他们会要求他们的 A.I GPT 模型为它编写代码吗？😂
如果他们真的这么做了，那将非常具有说明性，尤其是如果他们将所有人工智能的垃圾代码原封不动地推到 github 存储库中，那么整个编程界都会对大语言模型(LLMs) 在关键任务和高可见度应用中的实际功能性生产中的无用性感到惊讶。
你难道不知道在专业环境中，大多数开发者不会直接提交AI生成的第一版代码吗？他们会提供反馈进行多次修订，或亲自手动修订？
我继续与AI迭代代码，直到它与我亲自编写的代码相似。
难道不是直接编写你原本会编写的代码更快吗？
通常不是。确实有少数情况可以，但我经常能在一两个小时内完成一个原本需要一两天才能完成的功能。
编辑：因为说自己成功使用了某种工具而被点赞，真是太有趣了。我很抱歉你们没有好的体验。这些工具是新的，需要实验和学习，但它们已经存在，我还有25到30年的职业生涯，我将继续实验新的工具，随着它们的演变。我会自豪地接受负面评价，但我鼓励你们继续关注这些工具，随着它们快速变化而尝试它们。
你在辩论中抛出一个空洞的陈词滥调。“1-2天的任务在1-2小时内完成”……好吧。也许这是最好的事情。也许这是一个微不足道的例子，只发生过一次。也许你是个编程速度慢的人。也许你在说谎。
你没有提供任何细节，因此这并不特别有说服力，也无法为讨论增添价值。即使是正确的。
有人问我是否更慢，并要求提供具体例子，所以我分享了我的例子。抱歉我没有提供统计数据或确切时间，我这里没有运行基准测试。
再次强调，如果你不想使用这些工具，那就不要用。我已经看到有工作面试开始围绕这些工具的适用性展开，所以你过你想要的生活，我过我想要的生活。
我不会因为你使用Cursor而获得佣金。
此外，我从事这一领域已有15年，通过将AI整合到我的工作流程中，也获得了巨大的收益。我正在重新构建我的项目，使其与开发容器兼容，这样我就可以在受保护的环境中运行Claude Code，而无需受限。
这样说可能有点好笑，但你为AI代理提供的“耐心和关爱支持”(包括优秀的项目文档、工具配置和指导文档，以及提醒从错误中学习)与你从AI中获得的输出质量成正比。我能给出的最佳建议是将AI视为需要帮助起步的真实实习生。我认为那些对AI抱有轻蔑态度的人会在这方面走捷径，并获得可预见的糟糕结果。
抱歉有人对你态度恶劣。你无需证明任何事情。
哈哈，没关系。人们害怕改变，而我们的发展方式极具个人化(试着说服某人更换编辑器，更不用说彻底重新思考他们的工作方式了)。
我相当确信自己正走在为未来“保障”职业发展的正确道路上(至少以当今标准而言)，尽管我内心深处确实希望事情不会朝这个方向发展。
有些人会迅速适应，有些人会慢慢适应，还有些人不会与时俱进。别人怎么做与我无关。
我同意，我也经历过自己对生活技能被商品化的绝望和否认的循环。但这无法改变。这是科技行业，我们本就需要一场变革。
显然正确。
你提到职业生涯还剩25-30年，这说明了一切，朋友。
你知道职业生涯有多长吗？我已经在这个领域工作了15年
所以，大概是30多岁到40岁出头吧？
我今年50岁，我今天的职业道路与10到15年前完全不同。我也不指望在60岁、65岁或70岁时会有什么不同。
我认为，技术领域中任何认为自己的职业生涯轨迹是恒定不变的人都是愚蠢的(无论他们是否对大语言模型(LLMs)等新工具和新技术持开放态度)。
但那不会是他当时会写的代码。而是他实际写的代码。这是完全不同的两回事。
这要看情况，但通常不是。显然。
“你能为我实现X吗？我希望在Z发生时它能做Y。”
[5秒内生成的可行但非理想解决方案]
“这看起来不错，但你能用这个代替那个吗？”
[5秒内生成的非常好的解决方案]
即使你确切地知道你要输入什么，但通常也无法像大语言模型(LLM)那样快速地输入结果。
不过，使用大语言模型(LLM)也会产生反作用的情况。有时，它会完全误解你的要求，或者陷入产生错误输入的循环中。但根据我的经验，我认为这是例外，而不是常规(人们会强烈反对这种说法)。
你怎么知道这是一个非常好的解决方案？时间必须包括你验证它是否良好的过程，而对于大多数使用此类工具的人来说，这往往是一个挑战。猜猜接下来会发生什么(我做出那个令人讨厌的《小鬼当家》表情)？
假设有人花了一两天时间编写代码，而你想对它进行非常仔细的审查。你会花一两天时间审查他们的代码吗？
更可能的情况是，你会下载代码，然后花30分钟到1小时进行深入审查/理解，然后提供反馈。你可能会等待几个小时，让反馈被整合并实施。
这里的区别在于，你提供详细的反馈，然后你的更改会立即被实施。
使用AI工具时，我更倾向于把自己视为编辑而非作者。
我的意思是，如果我们只是在编造数字，那讨论的意义何在？
老实说，我认为像你这样的人从未使用过大语言模型(LLMs)。
如果你只需要实现几个功能，那么 5 秒钟是完全合理的。你生活在什么世界里？
你觉得你能理解大语言模型生成的代码吗？如果是的话，为什么自己编写代码会如此困难呢？
是的，我理解代码。自己写更难是因为我得花时间亲自打字。
这是个认真的问题吗？
想想你在手机上打评论要花多长时间。
如果用语音转文字，速度会提升多少。
如果能直接按想法打字，速度又会提升多少。
然后，如果给出一个大致的估计，速度提升是完全输入并格式化的。
我认为答案是肯定的，但这种人工智能对那些拥有赌博基因的人有吸引力。我试图抵抗它，但我确实是个瘾君子，我能感受到那种轻松解决问题和获得无需亲手编写代码的满足感。
这永远不值得，而且它节省的时间永远少于它消耗的时间。另一方面，老虎机总是让你亏钱，但我周末在拉斯维加斯看不到很多空座位。我认为AI在某种程度上会引发成瘾。听人们为使用AI辩护，听起来就像一个瘾君子在为自己的行为辩护。
我不是说人工智能整体上是坏的，但依赖它来生成除了学习之外的任何代码，都只是一个没有好处的昂贵努力。而且人工智能会话中的反馈循环与许多过程成瘾触发器带来的那种令人兴奋的感觉相同。至少对我来说是这样。
是的，完全不是，这些工具在某些领域确实对人们的生产力产生了可量化的影响。我的情况也是如此。
忽略关于奇点、通用人工智能(AGI)和气候影响的争论。工具本身的好坏取决于使用它的人。
我使用这些工具来生成我已经明白自己想要什么的代码，是的，在许多情况下它确实能更快地完成任务(而在某些情况下它不能，但对工具的经验帮助我明白何时使用它以及何时不使用)
不。我之前尝试用Python以几种方式实现，但不确定哪个版本的Python能满足我的需求，我试图实现的是非常底层的功能。我也尝试了Java版本。所有程序基本实现了我的需求，但底层实现细节并未按预期工作。我现在不确定我想要的功能是否可行。但如果可行的话，Java应该能实现。我确实可能需要自己编写一些代码，但这将花费我几天时间，而我之前做的事情只花了几个小时。
其中很多内容并非“编写程序”，而是十年前我不得不通过管道连接一些Unix工具来实现的任务。如今我可直接请求Gemini生成一个100行代码的定制Java程序，其可读性远超十年前我会编写的Bash单行命令，且能提供关于运行过程的详细输出。
https://youtu.be/Yf_1w00qIKc?si=qIoydg-e4HjSq8VV
参与Claude代码开发的团队成员使用CLI进行Claude代码开发。
他表示自己数月未编写单元测试
我认为这是人们对使用大语言模型(LLMs)来加速编码持负面看法的基本原因。很多人只熟悉 GithHub copilot 的“代码猴子让它工作，构建我的应用程序”的心态，而不是规划和限制工作范围、审查代码以及对 AI 生成的代码进行迭代。
审查他人的代码并非工作最令人愉快的部分，但它不像修复他人的代码那样令人讨厌。
当那个“他人”是一个自动化的傻瓜时，我看不出来有什么吸引力。
这不是关于你喜欢做什么，而是关于什么是最有生产力的。
我不明白在流程中添加一个白痴(无论是否自动化)如何能提高效率。
此外，这同样与我们喜欢做什么有关，因为不喜欢自己工作的人会转而从事自己喜欢的工作。
你缺乏细微的差别。这并不像“大语言模型(LLM)是个白痴”那么简单。在某些方面，大语言模型比你聪明得多。但在其他方面，它却不如你聪明。
那个家伙不应该承认，对大语言模型(LLM)进行迭代并不那么有趣。我认为，如果你总体上更高效，事情进展得更快，你会更享受它。
好吧。一个吸食可卡因的白痴。它非常快地表现得像个白痴。
鉴于它无法推理，所以答案是否定的。
这就是我所说的缺乏细微差别的观点。坦率地说，这很奇怪。
你可以让大语言模型(LLM)阅读 10 页的文件，并在 15 秒内以非常高的准确度进行总结。如果你不觉得这很了不起，也不认为这是一种智能的表现，那么我不知道你生活在什么世界里。
似乎你的问题是，你只是把婴儿和洗澡水一起扔掉了。大语言模型(LLMs)不能做某些事情——因此它们是无用的。再次重申——情况比这更微妙，但显然你的想法已经定型了。
你缺乏机智。
没错，但如果你选择变得不高效(相对于其他员工)，那么你的价值就会下降。你会赚得更少，对雇主来说吸引力降低，最终在该行业中变得难以就业。
> 我不明白为什么在流程中加入一个白痴(无论是否自动化)会更高效。
这是一个非常快速的白痴，可以被引导到你喜欢的方向。目前我还不确定对于大多数任务来说使用AI是否值得，但随着技术的发展，它会变得值得。
我认为，承认编写代码对某些人来说是工作中有趣的部分，这是可以的。如果(这是一个很大的如果)软件开发最终只成为协调大语言模型(LLMs)的工作，我认为我们会看到一部分开发人员决定完全离开这个行业。生活不仅仅是为了最大限度地提高生产力。它还关乎个人成就感。并不是每个人都能从最大限度地提高股东价值中获得成就感。
我怀疑编码会变成只是协调大语言模型(LLMs)。总会有一些事情它们太笨而无法处理，比如新颖的解决方案，或者更普遍地说，它们没有接受过培训的事情。但它们绝对会变得足以胜任大多数开发工作，这些工作基本上只是 CRUD。
我认为你说的其他内容与我的观点基本一致，只是角度不同。你只能适应、离开，或被淘汰。
你正在忘记如何编程，所以我更担心你自身的价值。
我认为比莉·乔说得最好：
不想添加一个自动化白痴
不想在新媒体下进行代码制造
你能听到歇斯底里的声音吗？
潜意识中的人工智能时代
欢迎来到一种新的紧张氛围
整个世界都充满疏离感
一切都不再美好
大语言模型(LLM)梦想着明天
我们不是那些应该追随的人
因为这已经足够争论了
不，我意识到大多数开发人员并不是只是做人工智能的垃圾。事实上，在荒谬的“氛围编码”趋势之后，“开发人员”实际上并不是“开发人员”的情况越来越多，他们不熟悉或没有接受过最佳软件工程实践的培训，不理解或几乎不理解大语言模型(LLMs)生成的代码，而且几乎没有能力或能力来调整大语言模型(LLMs)生成的垃圾代码。
人们坚持反复提示，直到大语言模型(LLMs)生成可用的、可维护的代码，这简直就是大语言模型(LLMs)作为自动代码生成手段完全不可靠的铁证。
我厌倦了大语言模型(LLMs)的故事线。它太糟糕了。它基本上是炒作。这对生物来说是不好的。从长远来看，它不会带来任何好处，也很少像人们所描述的那样成为万能药。目前还没有基于大语言模型(LLM)的杀手级应用程序，而且很可能永远不会出现。
这可能是真的，但如果真是这样，那是因为现在的‘开发者’数量是以前的10倍。我们并没有失去任何开发者，而是获得了许多脚本小子，其中一些人会成长为真正的开发者，另一些人则会用脚本做一些以前无人能做到的事情。
我们拭目以待吧。最近的实证研究表明，我们对大语言模型(LLMs)的依赖正在积极地导致大脑退化和神经通路的减少。鉴于目前的情况，这些脚本小子们可能也会退化……
老兄，研究表明，当婴儿潮一代还是孩子的时候，电视也有类似的影响。大语言模型(LLMs)出现的时间还不够长，无法进行经验研究来了解“大脑退化”的问题，虽然这种现象确实存在，但原因却多种多样。通常情况下，真正导致大脑退化的不是计算机，而是微生物。计算机最有可能通过辐射导致大脑退化，但家用计算机产生的辐射量并不大，不会造成问题。
实证研究是实证的
你声称大语言模型(LLMs)会导致“大脑腐烂”，或者随着时间的推移，会主动使你的大脑功能下降，但该研究并未如此表述，即使如此，这也只是一篇论文，你需要进行重复研究和同行评审，才能开始做出这样的断言。而且，大语言模型(LLMs)的发展速度如此之快，以至于没有时间进行这样的研究，已经完成的研究应该是使用 GPT3.5 进行的，而 GPT3.5 与 o1 或 Gemini 2.5 Pro 的行为截然不同。你的“实证研究”并不存在，即使存在，也与明年人工智能的影响无关。
[deleted]
你声称大型语言模型(LLMs)会导致“脑力衰退”或以某种方式使大脑功能随时间推移逐渐恶化，而该研究并未提及这一点，
根据论文内容：
脑电图(EEG)显示脑部连接性存在显著差异：仅使用大脑的参与者表现出最强且最广泛的脑网络；搜索引擎用户显示中等程度的脑活动；而大型语言模型用户则表现出最弱的脑连接性。
这种连接性下降就是大脑退化。
即便如此，这只是一篇论文，需要重复实验和同行评审。
重复实验是一回事。是的，我确信这些结果将在合理时间内得到重复验证。至于同行评审，您是否暗示麻省理工学院的论文在预发布前未经过同行评审或监督？
大语言模型(LLMs)的发展速度如此之快，以至于没有时间进行同行评审。
这无关紧要。我们现在就可以测量连接失败的情况。
已经完成的研究是使用 GPT3.5 进行的，与 o1 或 Gemini 2.5 Pro 相比，GPT3.5 的行为截然不同。
那又怎样？
你的“实证研究”并不存在。
我提供了摘要的链接。以下是一些评论文献和引用：
总体而言，访谈还表明，与其它组相比，使用大语言模型(LLM)的志愿者对他们的论文的归属感较弱。ChatGPT 用户在撰写论文后不久也难以回忆或引用自己的论文。在所有衡量标准(大脑活动、语言分析和论文评分)中，依赖 ChatGPT 的参与者表现都比仅依赖大脑的组差。
在我看来，这听起来像是大脑退化。
听起来很熟悉 https://en.wikipedia.org/wiki/Is_Google_Making_Us_Stupid
抱歉，但你只是在展示你对这些工具的了解有多么有限。
许多能干的工程师每天都在使用它们，而不仅仅是向大语言模型(LLM)输入内容，然后祈祷一切顺利。我的所有代码都是由大语言模型(LLM)生成的吗？完全不是。它是否让我在某些情况下/某些用例中效率显著提高？是的。
我同意，大语言模型(LLM)的炒作周期确实让人难以接受，就像管理层追捧的任何技术炒作周期一样，但这些工具不会消失，而且可能会变得更好、更有用。
我足够年长，记得动态类型和垃圾回收曾面临类似的质疑。它们都被指责为培养了一代懒惰的开发者。然而，这个行业仍在前进……
你多大了？至少八十岁了吧？如果你不是，那你 simply 没经历过垃圾回收和动态类型首次流行起来的时代。
糟糕的类比。垃圾回收和动态类型的出现仍是编程和编程语言设计的核心。AI 垃圾则不然
Claude代码是用Claude代码编写的
https://youtu.be/Yf_1w00qIKc?si=qIoydg-e4HjSq8VV
我才不会看那个愚蠢的视频。显示克劳德生成的代码和生成代码的克劳德提示的公共 git 存储库在哪里？
此外，u/vibecodermcswaggins 你的用户帐户今天已经创建 111 天了。你所有的(或几乎所有的)帖子和评论都与大语言模型(LLM) 或克劳德有关。你的议程和偏见在这一点上显而易见。你在r/programming及其相关子版块传播你的胡说八道，这令人作呕且可耻。
我兄弟，我为什么要传播Claude代码
我是一名临床精神科医生，正在努力学习编程
你的愤怒是错误的
我说的什么让你这么生气？
https://github.com/anthropics/claude-code
你的账号只有106天。仅供参考。
不知道。我也不明白你想表达什么。
这说得通。
太好了！希望你能避开人工智能的垃圾，从可靠的来源如SICP(最好是Lisp版本)学习软件工程的最佳原则和实践。
你的假设是侵入性和不受欢迎的。
你提供的视频链接没有上下文或解释，这让我感到愤怒。
那不是代码库！CLI 没有源代码
是的，那又怎样？
快速浏览我的个人资料即可发现，我对各类主题和兴趣领域都有所评论，而你过去111天来主要在为AI垃圾内容做宣传，且用户名中包含“vibe coding”的字样。我的用户名则引用了Church-Roster定理，进而延伸至Lambda演算。Vibe 编程只是一个昙花一现的 meme 趋势，被那些缺乏常识的盲目追随者和风险投资支持的炒作者炒作起来。而 Lambda 演算则是两种主要的计算形式系统之一，可以用于构建图灵机……
是的，他们已经在这么做了。我编写了 rust 重写中使用的 rust crates 之一，并收到了团队生成的代码库 PR。
[已删除]
即使在干净的编译之后，逻辑错误仍然有可能发生。尤其是人工智能
如果他们日常工作中没有使用 Cursor 或类似的东西，我会非常惊讶。
又一个重写成 Rust 的项目
又一个加入 Rust 的项目
另一个用 Rust 重写，肯定的
原始 GitHub 讨论：https://github.com/openai/codex/discussions/1174
我希望他们能将ChatGPT应用重新编写为非Electron架构。
那个网站糟糕得令人发指。从现在起直到永远，我绝不会再使用它。
/r/singularity告诉我，o3会一击致胜。
为什么 TypeScript 成为这里的头条新闻？他们基本上是在放弃 NodeJS，转而使用 Rust。TypeScript 只是细节问题。
因为 TypeScript 至少与 Rust 有相似的类型系统，从 js 切换到 rust 非常容易。TypeScript 意味着实际上还有一些考虑因素，可以继续使用该语言。
我明白这一点，但他们给出的切换理由是：性能、可移植性和更少的依赖项，这些都很有道理，但这并非 TS 的特性或问题。这是 Node 及其生态系统的问题。TS 只是 JS 的超集，这一点你一定清楚。所以，实际上，这是从 Node 项目迁移到 Rust，但文章却到处都在谈论 TS——好像它就是语言本身——而只提到一次 Node——好像它只是某种依赖项。可比较的类型系统只是与迁移过程相关的细节。
最近代码库仓库的提交有两周中断。我差点以为他们放弃了 CLI，转而全力投入 Web 版本。
这听起来像是向投资者展示“我们在做事情”的好方法。
恶心
当像 AirBnb 这样非常注重 UI/UX 的公司这样做时，这种做法就很有意思。糟糕的 JS 会造成很大的延迟，删除它可以让最终用户享受难以量化的体验。
这些都不适用于 openAI！限制因素是大语言模型(LLM)！这就像买一辆法拉利来更快地上班一样。福特嘉年华和法拉利都必须在红绿灯前停下来。
我非常清楚这一点。你是不是自闭症患者？
好吧，至少有一项研究表明神经功能会在一段时间内衰退。目前尚不清楚这种衰退是否会以显著且可量化的方式持续存在，但麻省理工学院研究的参与者确实出现了可量化的神经功能衰退(至少是暂时的)。
可能有，但目前没有。虽然不同，但你的观点我明白。
时间会证明一切，我们拭目以待。你可能会注意到，我在关于这个问题的热门评论中已经指出了这一点。
再次重申，我并不是单方面断言这种下降是必然的或显而易见的。但我确实认为，我们似乎还无法对使用大语言模型(LLMs)时的认知功能进行经验性测量，而且这种转变随着时间的推移可能会带来有害的影响。
相当不错，因为打字稿版本完全出乎意料地充满了错误。
让我们看看 Rust 如何为他们解决这些错误。
我并不是说 Rust 不好，只是说他们的“充满错误的混乱”很可能是由他们自己的缺陷造成的。
没错，如果你真的不擅长编写代码，那么无论使用哪种语言，你都会写出糟糕的代码。然而，rust 有许多保护措施，至少可以帮助那些糟糕的开发人员编写出还算不错的代码。
我不知道为什么不是 Go 🤪
放弃？我已经使用Rust CLI有一段时间了。它支持MCP，并且拥有更多的配置选项，不过我发现它比另一个版本更容易出现卡顿现象。
等他们完成后，我打算用Go语言重新实现整个系统。