返回首页
最新
我一直在探索一种新的系统语言设计，围绕着一个严格的原则构建：
数据的生命周期与创建它的词法作用域完全一致。
外部作用域永远不能保留对内部分配的引用。
没有垃圾回收（GC）。
没有传统的Rust风格借用检查器。
没有隐式生命周期。
没有隐式引用计数。
当一个作用域退出时，内部分配的所有内容都会被确定性地释放。
---
以下是代码中的基本思想：
```rust
fn handler() {
let user = load_user(); // 任务作用域分配
CACHE.set(user); // 编译错误：从内部作用域逃逸
CACHE.set(user.clone()); // 显式逃逸
}
```
如果数据需要逃逸作用域，必须显式地克隆或移动。
编译器在编译时强制执行这些边界。
没有运行时的生命周期检查。
内存管理成为一种结构不变式。
程序结构使得错误使用无法表示，而不是依赖于运行时跟踪生命周期。
并发遵循相同的封闭规则。
```rust
fn fetch_all(ids: [Id]) -> Result<[User]> {
parallel {
let users = fetch_users(ids)?;
let prefs = fetch_prefs(ids)?;
}
merge(users, prefs)
}
```
如果任何分支失败，整个并行作用域将被取消，内部的所有分配都会被确定性地释放。
这在字面意义上是结构化并发：
当一个并行作用域退出（成功或失败）时，其内存会自动清理。
失败和重试也是显式控制流，而不是异常状态：
```rust
let result = restart {
process_request(req)?
}
```
重启会丢弃整个作用域，并从干净的状态重新尝试。
没有部分状态。
没有手动清理逻辑。
---
我认为这有意义的不同之处在于：
该模型是围绕封闭性构建的，而不是熵。
某些不安全状态的防止不是依靠约定或纪律，而是依靠结构。
这消除了：
* 隐式生命周期和隐藏的内存管理
* 内存泄漏和悬空指针（作用域是所有者）
* 跨不相关生命周期的共享可变状态
如果数据必须比作用域活得更久，这一事实必须在代码中显式体现。
---
在这个阶段我想要学习的内容：
1. 可扩展性。这个模型能否在长时间运行的高性能服务器中工作，而不依赖于GC或普遍的引用计数？
2. 效果隔离。I/O和副作用应如何与基于作用域的重试或取消交互？
3. 代际句柄。这个模型能否在不造成过多开销的情况下替代传统借用？
4. 失败模式。与Rust、Go或Erlang相比，这个模型在哪些方面会崩溃？
5. 可用性。哪些常见模式变得不可能，这些是有用的约束还是致命缺陷？
---
一些额外的想法，仍在探索中：
* 具有时代风格管理的结构化并发（没有全局原子操作）
* 每个核心严格固定的执行区域，具有无锁分配
* 仅在崩溃时重试，失败总是丢弃整个作用域
---
但核心问题是：
像这样的严格作用域封闭内存模型在实践中真的能有效工作吗，而不会悄然重新引入GC或传统的生命周期机制？
注意：这并不是“Rust但不同”或对旧系统的怀旧。
这是探索一种根本不同的思维方式来理解内存和并发的尝试。
我非常希望能得到关于这个模型的批评反馈——它在哪些方面有效，在哪些方面崩溃。
感谢阅读。
我之所以构建这个，是因为我想要一个简单的、类型安全的 Java 客户端，用于 Google Gemini，能够原生支持 ReAct 代理，而不需要 LangChain4j 的繁重框架。现在它还支持本地 ONNX 嵌入和 pgvector。欢迎反馈！
我不是技术专家，也不在科技行业工作，因此这是一个外部观察者的视角。关于通用人工智能（AGI）的市场宣传承诺了斯皮尔曼的g：一种能够适应新问题、未见问题的通用流动智能。然而，工程方面——特别是“专家混合模型”和独立模块——看起来与J.P.吉尔福德的智力结构完全相同。吉尔福德将智力视为大约150种具体的、独立的能力的集合。
问题不仅在于这些部分是如何拼接在一起的。我看到的问题是：当模型面临一个不符合其预定义部分的问题时，会发生什么？他们将如何确保输出不会显得支离破碎，而架构又依赖于在专门“专家”之间切换，而不是使用统一的推理核心？
具体技能的集合（吉尔福德）与适应任何事物的能力（斯皮尔曼）并不相同。通过优化特定组件，我们正在构建一个在已知任务上表现出色的系统，但可能在真正的通用智能所需的流动推理方面根本缺乏能力。我并不是反对人工智能；我只是觉得我们可能需要重新审视我们的做法。我们不能指望在错误的高速公路上到达正确的目的地。
我已经使用Claude Code运行长时间的编码代理大约六个月了。Steve Yegge在十月份发布了Beads，我发现为Claude提供适当的任务跟踪工具是一个巨大的突破。然而，Beads在短时间内迅速增长，每次发布都使其变得更加缓慢和令人沮丧。我开始每周多次与它斗争，因为它的后台守护进程在错误的时间同步错误的内容。
在假期期间，我终于将其移除，并编写了ticket作为替代。它保留了我真正关心的核心概念（基于图的任务依赖关系），但去掉了其他所有内容。
ticket是一个基于coreutils的单文件bash脚本，用于管理平面文件。当你有awk时，不需要用SQLite对所有内容进行索引。它只是一个小型的管道工具，能够让你专注于工作。
我很想听听大家对不足之处的反馈。我是为自己的代理工作流程构建这个工具的，所以可能还有一些用例我没有考虑到。