标签
C++26 引入了新的 <debugging> 头文件，提供 std::breakpoint()、std::is_debugger_present() 和 std::breakpoint_if_debugging()，通过提案 P2546R5 和 P2810R4 实现标准化，以取代平台特定的调试宏。
一篇由 Gleam 粉丝撰写的深度文章，深入探讨 Gleam 的 case 穷尽性检查机制，分析 compiler-core/src/exhaustiveness.rs 源码，并将模式匹配的编译理论追溯到 Lennart Augustsson 于 1984 年发表的论文《Compiling Pattern Matching》。
一份关于 C++26 契约特性（P2900）的入门教程，介绍前置条件与后置条件如何取代传统的基于 assert 的检查，并涵盖编译器选项、求值语义及常见陷阱。
一条推文引用了埃隆·马斯克关于未来的观点：软件将不再以人类可读的代码形式存在，人工智能模型可以直接生成机器码，人类只需描述需求并验证结果。
Scala 创始人 Martin Odersky 认为，类型将成为人类与 AI 生成代码之间的契约，帮助人类在 AI 大规模编写代码并利用漏洞的情况下保持控制权。
Rust 语言设计师 Niko Matsakis 撰文探讨 LLM 智能体（agentic development）对编程与编程语言设计的影响，认为 Rust 的类型系统和可靠性使它非常适合智能体驱动的开发，并展望如何进一步强化这一优势。
标题指出在 Rust 借用检查器中发现了存在 11 年之久的不健全性缺陷，内容实际为 Rust 主仓库的 README。该发现对 Rust 的内存安全保证具有重要意义。
Valen 的新文章介绍了一种更灵活的借用检查器（group borrowing），编译器会记住引用指向的位置，以实现比 Rust 更简单灵活的内存安全方案，并已被 Google Carbon 等语言采纳。
一篇由 Rust 程序员撰写的博文，记录了其自学 C 语言过程中遇到的各种奇特行为，包括通过 <stdbool.h> 实现布尔类型、以 null 结尾的字符串与 Rust 中长度前缀的 &str 之间的对比，以及相关的内存权衡。对于从 Rust 转向 C 的开发者来说，它是一份实用的配套指南。
Alan Kay 于 1993 年在 HOPL-II 会议上发表的论文回顾了 Smalltalk 在 Xerox PARC 的早期历史，追溯其根源：20 世纪 60 年代的人机共生研究、FLEX 机器、SketchPad/Simula，以及走向面向对象设计的 Dynabook 愿景。
一篇观点文章，论证 Common Lisp 现在是最好的编程语言，因为大语言模型将瓶颈从编写代码转向了快速反馈循环、基于实时镜像的开发、交互式调试器，以及通过宏驱动的领域特定语言来削减代码量和 token 成本。
Oracle Java 平台组的 Ron Pressler 解释了 Project Loom 的理论动机——该项目旨在为 JDK 添加续体（continuations）和纤程（fibers），以简化 Java 中的非确定性 I/O 与并发编程。
DHH 让 AI 智能体用 Elixir、Go 和 Rust 重写了 Basecamp 的聊天应用 Campfire，性能相比 Ruby 差距近 150 倍，并指出 AI 智能体写代码可能会让语言选择的标准从开发者体验转向运行时效率。
一篇讨论帖提出：既然大多数代码将由 LLM 编写，我们是否应该专门设计一种面向 AI 的语言——用户只需描述意图和约束条件，而编译器负责决定使用 Go、Java 或 SQL 等语言的具体实现方案。
这篇1989年的论文介绍了Self语言编译器，提出了按接收者类型进行过程定制、基于运行时测试的推测性类型预测、调用拆分以及激进内联等技术，使动态类型面向对象语言的性能提升了一倍，并为后来的现代JIT编译器提供了借鉴。
一段演讲纪要：工程师讲述从与 Node 分手、爱上 Rust、到用 Rust 创办 Oxide Computer Company 并为 illumos 移植 Rust 支持的全过程，以及 Rust 的严谨性与性能价值观如何成为公司文化基石。
一场讨论认为，Rust 作为 AI 编程代理默认语言的地位可能不保，原因是编译时间过长，而编程代理在其他语言中的手动内存管理能力日益熟练。
一篇博客文章指出，尽管编程语言研究者中弥漫着一种"存在主义危机"的情绪，担心人工智能会让人不再编写代码，但这个领域正进入一个前所未有的探索时代：大语言模型加速了研究进程，而编程语言领域那些优美的理论思想依然魅力不减。
对 Peter Bex 的访谈——他是 CHICKEN Scheme 的维护者，也是职业 Clojure 开发者。访谈内容涵盖他从 C64 BASIC 走向 Lisp 的经历、对 CHICKEN Scheme 的核心贡献（数值塔、irregex、安全修复），以及他对 Scheme 社区、Racket、Postgres 和 Clojure 的看法。
Futhark 团队解释了为什么他们的编译器 GPU 流水线会把所有数组都强制迁入 GPU 内存，这使得顺序的 CPU 侧工作（例如针对稀疏雅可比矩阵的贪心距离-2 图着色）慢了三个数量级；他们还描述了一种变通方案，让部分函数留在 GPU 之外，同时程序的其余部分仍然能够利用 GPU 的并行能力。