“缓慢且臃肿”的代码时代正在走向终结，AI 极大地降低了高性能工程的门槛。过去，手动性能优化需要稀缺且昂贵的专业知识；而如今，AI 智能体可以在几分钟内完成复杂的优化工作，例如即时编译（JIT）、多线程处理和定制化引擎调优。 这种转变推动软件向“动态定制化”方向发展，应用程序可以针对特定工作负载进行调优，而非针对所有用户进行通用化设计。在 AI 驱动的正则表达式引擎调优和多线程游戏 AI 的实验中，AI 智能体展现了执行复杂、繁琐优化任务的能力——这些任务往往因耗时或复杂而常被人类忽略。即使智能体缺乏人类水平的战略判断力，它们快速迭代的能力也足以在明确定义的性能任务上超越经验丰富的工程师。 虽然这些工具需要严谨的实验设计以避免过拟合，但优化的“成本”已经下降了几个数量级。曾经需要数周甚至无法完成的复杂技术工作，现在一个周末即可实现。这预示着未来软件可以针对个人数据模式和特定硬件进行激进的优化，低效代码将变得越来越不被需要。
每日HackerNews RSS
这篇 Hacker News 讨论聚焦于一个激进的观点：“多亏了现代大语言模型驱动的开发，软件再也没有理由变慢了。”
**核心论点：**
* **优化的可能性：** 支持者认为，大语言模型现在可以处理繁琐的性能调优工作，例如实现 SIMD 内在函数、内存打包，或使用底层语言重写性能瓶颈——这些工作以往需要稀缺的专业知识和大量时间。他们认为，现在我们有能力默认以高性能为目标进行开发。
* **激励机制的现实：** 怀疑者反驳道，软件变慢很少是因为缺乏知识，而是由于业务优先级所致。功能开发、上市时间以及（使用臃肿框架带来的）“开发效率”被置于速度之上。正如一位评论者所言，“商业人士总是会选择新功能”而非微小的性能提升。
* **架构与代码：** 许多人认为，“缓慢”往往是系统性的——由不必要的网络往返、本地任务的“云优先”架构以及臃肿的依赖项（如 Electron/SPA）引起。大语言模型可以修复代码，但往往难以纠正糟糕的架构决策。
* **“体验感”问题：** 评论者强调，现代软件经常充斥着无用的动画和遥测技术，从而降低了用户体验。这往往是因为开发人员在高端机器上进行开发，而忽略了应用程序在普通硬件上的运行表现。
Show HN：Rex，一种用于科学工作流的并行函数式语言 Show HN: Rex, a parallel functional language for scientific workflows
2 天前
Rex (Rush Expressions) 是一门静态类型、纯函数式语言，专为科学计算和可复现的数据处理而设计。与依赖复杂 Shell 脚本或 YAML 的传统工作流系统不同，Rex 使用一种简洁且富有表现力的语言，将数据流、控制逻辑和错误处理定义为针对不可变值的纯转换。
主要特性包括：
* **内容寻址存储 (CAS)：** 使用 BLAKE3 哈希算法来标识并去重制品，确保数据不可变性和精准的溯源。
* **类型化工具 API：** Rex 不直接使用原始 Shell 命令，而是将特定领域的操作（如 FFmpeg、ImageMagick、QPDF）公开为类型化函数，从而在执行前杜绝配置错误。
* **隔离性：** 工具调用可以在受限的 Docker 容器中运行，无需访问网络或查看宿主系统，确保环境的可复现性。
* **可扩展性：** Rex 同时作为命令行工具 (CLI) 和可嵌入的 Rust 库进行设计，允许开发者在保持严格编排边界的同时，注入自定义的科学或模拟操作。
通过将分析逻辑与基础设施策略分离，Rex 提供了一个简洁、可审查且可并行的框架，特别适用于由大模型 (LLM) 生成或与其交互的流水线。
抱歉。
作者认为，Odin 的内联汇编系统是目前所有编程语言中最好的，因为它将汇编视为一种**具备类型和语义理解能力的语言组成部分**，而非仅仅是作为“逃生舱”的字符串。 大多数语言使用基于字符串的“补丁”系统（如 GCC/Clang），这些系统缺乏类型安全，依赖晦涩的约束字符串，且由于编译器无法真正理解汇编代码，导致错误报告效果很差。相比之下，Odin 的设计具备以下特点： * **语义集成：** 汇编被组织为类似过程（procedure）的“模板”。编译器利用一个库（rexcode）在编译时检查指令、操作数类型和寄存器。 * **统一语法：** 在所有指令集架构（ISA）中采用一致的上下文无关语法，并优先使用 Intel 风格的“目标优先”语法，以更好地与 Odin 的赋值逻辑保持一致。 * **类型化操作数：** 该系统利用 Odin 的类型系统来处理寄存器、位宽和寄存器破坏（clobbers），从而实现了诸如多返回值和卫生的局部标签等功能。 * **显式控制：** 开发人员不再使用晦涩的约束，而是使用清晰的命名绑定来处理引脚、临时寄存器和关联。 得益于一个经过验证的指令编码库，Odin 的系统仅用了七天就构建完成，并有效取代了对复杂编译器内置函数（intrinsics）的需求。
抱歉。
正在检查您的浏览器...需要启用 JavaScript
抱歉。
OpenTelemetry (OTel) 是一个至关重要但十分复杂的项目，旨在建立一个独立于厂商的可观测性标准。尽管它完成了使命，但用户经常抱怨其进展缓慢，且相比“傻瓜式”的厂商 SDK，其学习曲线过于陡峭。
对该项目的分析显示，这些延误源于一种“三方掣肘”：过于宏大的目标（涵盖数十种语言和框架）、对稳定性的刻板承诺，以及极其匮乏的维护者团队。由于 OTel 将长期稳定性置于首位，每一项变更都要经过严格审查，这造成了瓶颈，而人手不足且多为志愿者的团队对此难以应对。
作者认为，OTel 目前的方法是不可持续的。为了改进，该项目应当：
1. **引入“Beta”层级**：允许在不担心过早标记为“稳定版”的情况下，获取可操作的用户反馈。
2. **提高维护水平的透明度**：承认并非所有语言 SDK 都具备相同的支持成熟度。
3. **公开招募更多维护者**：从业余爱好模式转向资源更充足、更务实的框架。
归根结底，OTel 正在做着英雄般的工作，但它必须改进其流程，才能继续作为商业解决方案的可行替代方案。
近期 Hacker News 上的一场讨论凸显了开发者对 OpenTelemetry (OTel) 的强烈不满。尽管用户普遍认可其实现“供应商中立可观测性”的目标，但许多人批评该项目“过度工程化”且深受“委员会式设计”之害。
主要抱怨包括：
* **过度复杂：** 批评者认为其 SDK 臃肿、具有状态依赖，且过于依赖“黑盒”式的自动插桩，这往往会导致非简单应用出现故障。
* **糟糕的开发体验：** SDK 被描述为难以学习、抽象程度过高，且不同编程语言间的实现极不统一。
* **性能开销：** 许多报告指出其 CPU 和内存占用过高，使得 OTel 在某些工作负载（尤其是无服务器环境）下成本高昂或运行缓慢。
* **架构臃肿：** 一些人认为将指标、日志和追踪整合进一个僵化的规范中是一个概念上的错误，并倾向于选择 Prometheus 或 Jaeger 等更简单、独立的工具。
尽管存在这些批评，支持者仍认为 OTel 是防止供应商锁定、并为大型系统提供必要模块化的必要标准。尽管学习曲线陡峭，支持者坚持认为，尽管存在缺陷，它依然是现代可观测性中最可行、中立的发展路径。
❯ 您在不更改文件的情况下检查此存储库。使用一个工具列出顶级文件，然后用一句话总结您的发现。 ◇ 推理摘要 │ 列出顶级文件 ▸ fs.list /root/common-lisp/frob READ ∙ 正在运行 fs.list · 00:00 ✓ fs.list cpu 0.001s · real 0.002s │ /root/common-lisp/frob │ d .git/ │ d .github/ │ d .qlot/ │ d bin/ │ d dist/ │ d docs/ │ d native/ │ d nix/ │ d recovery/ │ d script/ │ d src/ │ … +13 行 ● autolith 该存储库是一个包含源代码、测试、恢复工具、文档、构建配置、原生资产以及 GitHub/Nix/Quicklisp 支持的 Common Lisp 项目。
**Autolith** 是一个利用 Common Lisp 创建实时、可自修改运行时环境的编程智能体。该项目由 Lucius Magn 开发，旨在利用 Lisp 独特的内省能力和基于镜像的开发模式，使人工智能体能够在实时 REPL 中直接检查、测试并更新其自身代码。
Hacker News 上的讨论揭示了智能体设计理念的分歧：
* **支持 Lisp 的观点：** 支持者认为，Lisp 规则的语法和极高的可塑性使其成为自我提升型智能体的理想选择。他们主张，智能体“生活”在镜像内部的能力，能够实现更优越的调试、迭代测试和低耦合代码，这比命令式、状态沉重的语言更能有效管理上下文。
* **持怀疑态度的观点：** 批评者认为，由于训练数据量巨大，大语言模型在广泛使用的语言（如 Python 或 JavaScript）中表现最佳。怀疑者认为，使用小众语言会引入不必要的摩擦，而智能体的主要目标应是完全抽象掉代码，将性能和可靠性置于底层语言的“优雅”之上。
作者计划进行智能体基准测试，以验证 Autolith 相较于现有工具的性能。
**Rust Glancer** 是一款全新的轻量级 `rust-analyzer` 替代方案，专为硬件配置有限或内存受限的开发者打造。该项目历时四个月开发，旨在通过摒弃传统 LSP 增量且耗内存的架构，将内存占用控制在 100MB 以内。
Rust Glancer 不会将整个工作区状态保存在内存中，而是采用“冻结”分析模型。它会对项目进行一次索引，将结果存储在文件系统中，并在需要时仅将必要数据加载到内存中。这种方法使得编辑器重启后能立即完成索引，并显著降低内存开销，非常适合老旧设备和多项目工作流。
虽然它的功能不如 `rust-analyzer` 全面，且由于涉及文件系统 I/O，在某些任务上速度较慢，但它依然是一款称职的日常开发工具。它支持类型推断、特征解析（通过 Chalk）以及跳转到定义和内联提示等常见的 LSP 操作。开发者在 LLM 的辅助下构建了该项目，同时保持了对架构的完全掌控。Rust Glancer 为那些愿意牺牲一点“按键级”响应速度，以换取更轻量、更高效资源体验的开发者提供了一个务实的选择。
抱歉。
五角大楼解雇了《星条旗报》的总编辑、一名资深记者以及该报发行人，理由是“不服从管理”。此前，总编辑埃里克·斯莱文（Erik Slavin）和记者劳拉·科特（Lara Korte）在接受哥伦比亚广播公司（CBS）采访时，公开捍卫了该军事媒体的编辑独立性，并批评了五角大楼可能存在的干预行为。 此举是美国政府试图加强对该刊物控制的持续行动的一部分。国防部官员已表示，希望将该报的报道重点从一般新闻转向严格聚焦“作战”和军事事务的内容。此次解雇在新闻自由倡导者中引发了强烈抗议，全国新闻俱乐部谴责此举是试图操控军事报道的“无耻行径”。 这些紧张局势与近期海军现役上校被突然任命为副发行人一事不谋而合，显示出其领导层正在发生转变。尽管五角大楼坚称仍致力于独立新闻报道，但撤换负责捍卫这种独立性的关键员工，已引发了外界对这家百年媒体未来自主权的严重担忧。
对不起。
这段文字反思了 Hacker News (HN) 作为平台的独特性。作者承认 HN 的评论经常不准确、无端刻薄，且比起建设性反馈，更像是“西蒙·考威尔风格”的尖刻批评。尽管如此，作者认为 HN 依然是进行技术探讨的最佳论坛。 与其他平台因耸人听闻的内容而淹没高质量信息不同，HN 的排名算法和对用户举报的高度依赖，有助于抑制争论，让专业且见解深刻的内容脱颖而出。作者指出，许多最有价值的技术讨论往往出现在评论区而非链接的文章中，但这些见解却经常被埋没。 本文同时也汇集了各类讨论中的“精华”，涵盖了广泛的技术和职场话题：MS Word 文件格式混乱的遗留问题、软硬件集成的复杂性（如戴尔的扬声器问题）、工程伦理、企业管理不善，以及创业公司与大厂工作的现实对比。最终，作者认为，尽管 HN 存在缺陷并偶尔伴有负面言论，但其汇集的专业知识使其成为科技界不可替代的资源。
抱歉。
Hacker News 上的一场讨论引发了关于贝尔维尤（Bellevue）和奥马哈（Omaha）警方采用电击“疼痛依从”手套的争议。
支持者认为，这些设备为其他武器提供了一种“非致命”的替代方案，有望减少使用极端武力的必要性。然而，批评者强烈反驳称，这些手套是“低视觉影响”的酷刑工具。由于这种手套不会像泰瑟枪或拳头那样留下可见的伤口或烧痕，反对者担心这会助长“懒惰执法”，并使警员能够在拘留过程中施加痛苦，而无需承担因可见伤痕或病毒式视频证据所带来的问责。
评论者将其与历史上的虐待行为进行了类比，并对暴力的常态化表示担忧，尤其是在针对在校学生使用时。讨论还涉及了设备的高昂成本、“疼痛依从”技术的伦理问题，以及为执法部门配备旨在规避公众监督的工具所带来的更广泛的社会影响。许多用户质疑，这种技术到底是有效地取代了降级冲突的技巧，还是仅仅为国家认可的虐待行为提供了一种更隐蔽的手段。